Let's say I have two tables in a database: projects and users. I create two models, that extend Zend_Db_Table_Abstract: Model_DbTable_Users
and Model_DbTable_Projects
.
Now, is it a good pattern to create an instance of Model_DbTable_Projects
inside the Model_DbTable_Users
class ? In other words: is it OK to put any logic in this model, or should I create another class, that uses Model_DbTable_Users
and Model_DbTable_Projects
?
I use to put all the logic in models, that extend Zend_Db_Table_Abstract, but in large projects it can make code very unclean. So, can you give me any advice on models architecture(links on articles would be great!).
I was the project lead for the Zend Framework project through version 1.0. My contributions were mainly in the Zend_Db component.
I frequently advise that people should use the Domain Model pattern and avoid the Anemic Domain Model antipattern. Remember that a Table is not a Model.
Your Model is a class (extending no base class) for code that encapsulates your business logic. The relationship between a Model and a Table isn't IS-A, it's HAS-A (or HAS-MANY). The Model treats database persistence as an implementation detail. The consumer of a Model should have no clue about your database structure (this allows you to change database structure without changing the Model's interface).
I'm basically repeating the answer I gave to Models in the Zend Framework.
Here is some more reading:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With