RE: [PHP] ORM doctrine

> -----Original Message----- > From: Peter Lind [mailto:peter.e.lind@gmail.com] > Sent: Sunday, December 12, 2010 5:27 AM > To: Lester Caine > Cc: php-general@lists.php.net > Subject: Re: [PHP] ORM doctrine > <snip> > > > > The reason for 'caching' needs to be understood before it is applied in > order to avoid the black holes that random caching is causing nowadays > already. How often do you hear "wipe the xxx browser cache"? And I know > if I am changing theme elements in bitweaver or phpgedview then I HAVE > to wipe the cache to ensure that smarty rebuilds the relevant pages. > > Which underlines my point: caching is not icing on the cake but should be > thought of sooner in the process, contrary to Tommys point. > > Regards > Peter > > -- > <hype> > WWW: plphp.dk / plind.dk > LinkedIn: plind > BeWelcome/Couchsurfing: Fake51 > Twitter: kafe15 > </hype> > If the app is well designed, then you still could implement it later w/o major rewrite. Example, suppose your new client currently doesn't see the need for auth/acl nor do they have the budget for it ATM. However, being experienced, you foresee their needs based their business, model & industry, how would you design the app so as to include that foreseeable future? Isn't that where knowledge and experience comes in? Request > acl/auth > process request > cache/db > return results. Isn't that how the core basic flow should be? Thus, if you removed acl/auth & cache, the app would still work. That's one of the things I've mentioned in Adam's thread of choosing framework or not, is the flexibility to pick and choose. Another example, would you use an array or a class object to represent the value of a row in a particular DB table? Some folks may make those decisions lightly. IMO, such important decisions would make all the difference in having "workable (learning, understanding, maintaining, etc.), reliable, and flexible (modular, 3rd party add-ins, etc.) code while retaining good performance." Regards, Tommy