> -----Original Message----- > From: Philip Thompson [mailto:philthathril@xxxxxxxxx] > Sent: Thursday, December 09, 2010 10:59 PM > To: php-general List > Subject: Re: ORM doctrine > > On Dec 10, 2010, at 12:00 AM, Paul M Foster wrote: > > > On Thu, Dec 09, 2010 at 07:41:32PM -0800, Daevid Vincent wrote: > >> > >>> -----Original Message----- > >>>> If you value CPU time over developer time, by all means avoid ORM > >>>> frameworks (and *all* frameworks). The point of a common > >>> framework is to > >>>> trade a small bit of performance for a large amount of > >>> developer time. If > >>>> you will only use the framework once, the payoff will be > >>> much less. The > >>>> goal is to choose frameworks that you can leverage again and again. > >> > > > > [snip] > > > >> > >> That's just it. DO NOT make a "framework". Make some helper routines > >> for common tasks like sql_query(), sql_insert(), sql_update(), > >> sql_select_box(), etc. and stick to the "basics". > >> > >> Frameworks are a waste of time and energy -- homegrown or off-the- > shelf. > >> They try to be all things to all people and turn into a "jack of > >> trades, master of none". They're bloated and cumbersome and force you > >> to wedge square pegs into round holes all the time. > > > > I have to agree with the "toolkit" idea. > > > > I just came off of job where they had an existing investment in > > Drupal, so we were stuck with it. No offense to any Drupalers out > > there. It's a very slick, cleverly thought out framework. But building > > anything non-trivial with the framework requires a significant > > learning curve and coding investment. And many things you'll want to > > do, you could do ten times faster by hand. > > > > This is the second framework I've done any significant research into. > > And my original decision to build a set of "tools" and use them for > > various tasks over and over seems the soundest course. The more those > > tools interlock, the more they become a framework, and the less > > flexible they become. > > > > The tools, used in a "habitual context" (models go here, views go > > there, > > etc.) makes for a much easier time of it. Not to mention that your > > thousands of site visitors won't be loading 150K of code each time > > just to view one page. (Yes, I've heard of caching. It's a system > > which was built to compensate for coders who waste too much CPU time > > and memory.) > > > > Paul > > I've used good ole' procedural PHP, built a homegrown "framework" and > now I use CakePHP, which has ORM. Yes, at first, it was a little confusing to > understand. But once you get it, it's really easy to create a database-driven, > dynamic application with little effort. Like most things in programming, you > have to find what works for you. While it is good to consider that others may > have to work with your _flawless_ code some day - so you better make it > understandable - many times clients just want what you can give them as > soon as possible. What I've found is that by using a framework (such as > Cake) I am able to give the client what they want... and quickly. If I ever run > into a problem that can't be easily solved by the framework, I resort to my > experience with "direct PHP" and just create a manual solution. That's the > beauty of PHP. > > CPU cycles are cheap and caching is there to speed things up, so I don't > completely understand those who complain about these things... > > Happy coding, > ~Philip The way I see it is this: 1) Thorough understanding of the problem: needs of the client/company, programming language in use, etc. 2) Thorough understanding of the objective of the application: answer the needs, capable of possible future growth/expandability, etc. 3) Well thought out application design to resolve the above 2: framework, mixed, or no framework. Thus, IMHO, caching is needed when one fails to fully meet the above 3 such as when the user clicks on any link in the browser, it should take no more than 3 seconds for the browser's status to be 'Done', provided that the user isn't on some 56k modem connection ;). (Naturally, the only exception to that is dealing with reports for data mining where millions of rows are involved. That's the DBA problem most of the time anyway.) Moreover, I see the needs of applications now to be more event driven than database driven. As of now, it's very rare to see an app w/o some kind of DB backend. Yes, CPU cycles maybe cheap but electricity and rack space aren't. There's a reason why Google chose to go with AMD rather than Intel a few years back during their server farm upgrade. It was pretty much a slap in the face for Intel when that decision made headline news. Regards, Tommy -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
