By your logic, the “clean” OO approach should descend from neither the Row or the Table. The DAL should be completely independent. However, I ran into some problems with this approach.

The reason I chose to descend it from Zend_Db_Table_Row because I generally want to interact with individual data objects, or collections there-in. I tried going through the clean OO approach originally, and it resulted in a lot of pass through code. It also broke record collections. In order to support collections coming from Zend, I ended up creating a lot of extra objects. Memory overhead was through the roof and the population algorithms got very expensive.

Another factor is abstraction for the fetching of data objects. I don’t want to assume that my application will be database based in the future. If I switch to something else, like SOAP or REST based model population, then a Table is no longer relevant. The idea behind the static methods for fetching ONLY is that it abstracts out the retrieval of records and it directly associates them to the type of object produced.

So, to summarize. I descend from the row, even though it isn’t as clean, because I want to utilize as much existing functionality from my DAL intact; the Zend Framework developers are better than I. Second, utilizing static accessors directly associates the fetch with the class/model it’s related to and it abstracts the fetch operation in case I decide to change my DAL in the future.