Re: [phpGroupWare-developers] Nested db-objects

[Maât]

Dr. Christian Böttger a écrit :
> Hi,
>
> Maât schrieb:
>
> > Rather than lock project evolution for religious reasons i think we 
> > need to separate the tasks
>
> standard procedures of software design like separation between 
> business logic and storage is NOT "religion". It's a standard method 
> for maintainable software development. It's not just done "for fun". 
> The *lack* of such "religious design ideas" in the eraly years of 
> phpGW is a main reason why we now do have so many bugs and "crap" to 
> fix in phpGW.
i will slightly disagree

we all know that abstraction layers are okay and beautiful theories... 
and sometimes so stupid when it comes to real usage with heavy loads 
that all abstraction and persistence layers have had more or less early 
in their lives to add disengage mechanisms so that they stop killing 
applications performances.
All of them need also a *very* serious training for developers to have 
them used properly... java layers like hibernate have given particularly 
illustrative cases of this gap between theory and real life.

And further more when it comes to very very heavy loads we sometimes 
have to use stored procedures with things like PL/SQL... choice which 
equals to put logics even behind the pure db layer. Religious extremists 
of MVC will scream heresy but i don't care : true facts and reality are 
stubborn things and prove that separation is a good way... often but not 
systematically.

Having, like all great frameworks, the possibility to disengage 
standards behaviours to do advanced things is not stupid design : it's 
just as framework design should be done... "powering but never limiting".

Keep in mind that a framework is there to allow quick and easy app 
developpement... many of these apps will be done without even you 
hearing of it (as "home made applications")... if these applications 
need to break pure separation for performance or other (good or bad 
)reason it's not up to us to decide instead of people how they *must* or 
*must not* use the framework.

On the other side, when it comes to standard and maintained 
applications, when it comes to API design we should, both as an example 
and for general quality (and performance, and security and 
maintainability) sake, respect separation as much as possible... and set 
the respect of  quality standards as a required criteria to have apps be 
granded a label (stable, maintained, core... whatever)

We need to make sure we all see well the difference between the 
framework itself , the application we build upon it, and the 
applications MM Doe or Smith could build for themselves.

There also we have a separation whe should respect as much as possible : 
the framework should be robust, stable and help people create quickly 
applications (dirty or not this is not our business... just their) the 
applications we provide should also, like the framework, be designed 
with quality and performance in mind (for them cleanlyness *is* our 
business)

But setting hard limits in the framework *is* religious intolerance... 
i'm sorry to insist but this is just plain truth.

> We will never get out of the cycle of "it works and solves todays 
> problem" and fixing tons of bugs later if we do not work a bit more on 
> software architecture and software design issues.

working on design weaknesses is a *very* good thing and please note that 
i'm not pleading for keeping shameful designs... i'm just putting 
emphasis that it's foolish to think that you will oblige people to think 
and design properly by setting locks in a framework... they will just 
use even uglier workarounds

Quality is a way of thinking design... locking things is not quality
> Regards
>
> CB aka bofh42
Sorry to disagree with you Christian

Maât