Question

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!).

Answer 1

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:

• http://weierophinney.net/matthew/archives/202-Model-Infrastructure.html
• http://blog.astrumfutura.com/archives/373-The-M-in-MVC-Why-Models-are-Misunderstood-and-Unappreciated.html
• http://n4.nabble.com/Another-Model-Design-Thread-td670076.html