Version:1.0 StartHTML:0000000149 EndHTML:0000004220 StartFragment:0000000199
EndFragment:0000004186 StartSelection:0000000199 EndSelection:0000004186 Over
the course of about 3 years, I built then lead a team to extend a fairly
large CakePHP-based project. Over the past 4 years or so I've built several
small to quite large systems based on Symfony. Recently, I've inherited a
fairly mature CakePHP-based project to take over...boy do I miss Symfony.
Refreshing my Cake memory...In all the discussions I've read recently
regarding Cake's insistence on effectively forcing us to use arrays rather
than properly hydrated objects to handle data, no one has stated the
obvious: treating application entities (or objects) as arrays actually makes
it *harder* to write proper MVC applications - it was simply a bad core
design decision. It largely defeats the purpose of the active record
pattern, leads to difficult to read and maintain code (filled with hideous
expressions like $myFoo["myBar"]["myProperty"], rather than the much more
elegant and easier to understand and work with
$myFoo->myBar->getMyProperty(), for example).
Keeping track of complex data structures and relationships as deeply nested
arrays is a nightmare now that I've gotten used to doing "real" Object
Oriented Programming...and an ORM is called that for a reason - instead of
being called an "Array Relational Mapper"...returning objects for your
application logic to work with is kinda the point...
So, what the original poster wants to do makes perfect sense in an OOP/MVC
context. He simply wants to add a $person->getAge() method properly to his
model, where the getAge method looks something like:
public function getAge()
{
// Assuming birth_date is stored as a unix timestamp.
// Of course you'd want to display this in a human-readable format, but
you get the idea...
return time() - $this->birth_date;
}
...then controllers, views, elements, etc all have access to it (although
you should be thoughtful about where you access it from)...in case you're
wondering, this is how Symfony works...
The ability to treat your models as objects encourages you to write fat
models. If your models are not much different than array
transformation/manipulation utility classes, I can understand people's
confusion...
The point of this post is not to slam CakePHP, it's a fine framework (so
hopefully I'm not inviting a flame war), but if you're looking to write
Object Oriented code instead of Array Oriented code, then perhaps Cake is
not for you. Don't let anyone tell you different: programming with objects
will make your life (and your company's/client's) life easier than working
with arrays - and it will make your projects more solid and easy to
maintain...and it's how advanced professionals do things, for what it's
worth. As I mentioned, I've done both extensively...but please tell me if
I'm missing something.
If someone replies with the usual mantra that arrays are better for
performance than objects, I think I'll hang myself - in this day and age of
computing, the antiquated "better performance" rationale just doesn't hold
water. With all the potential performance bottlenecks that can pop up in a
complex application, the core datatype transport being used might not even
make it on to your top 20 items to optimize - because it's ultimately just
not that important, relatively speaking...it's like worrying about where to
put a coffee cup when you begin to move into a new home - you should
probably be thinking about where to put the sofa first...using arrays
instead of objects was a neat idea in 2004, but now it's just a
counter-productivity pain...
I suppose I'll have to get used to thinking in terms of arrays instead of
actual objects for the project I'm working on...and it's said that human
beings can get used to just about anything...but it just feels like I'm
going "backwards"...
Happy coding to all...and always choose the right tool for the job :)
-SS
--
Our newest site for the community: CakePHP Video Tutorials
http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others
with their CakePHP related questions.
To unsubscribe from this group, send email to
[email protected] For more options, visit this group at
http://groups.google.com/group/cake-php
