Re: [fw-db] Zend_Db_Table and primary keys...

Ralph Schindler-2 wrote:
>
>
>>
>> Ideally, Zend_Db_Table_Abstract would derive from an ancestor class (for
>> example, Zend_Db_TableDataGateway) which would only take care of stupidly
>> mapping to a table or view without any logic related to relations. You
>> wouldn't have the find() method, but all functionality that don't depend
>> on
>> primary keys like fetchAll(), insert, delete and update (that don't take
>> primary keys as parameter, only a list of wheres) etc would be
>> implemented
>> in that class. Zend_Db_Table would implement primary key and relational
>> functionality.
>
> I actually do like this idea. I think when 2.0 comes around we should
> evaluate de-coupling the RowGateway from the TableGateway too. Can you
> add these ideas to the wiki?
>
> http://framework.zend.com/wiki/display/ZFDEV/Zend+Framework+Components+-+Developer+Notes
>
>> What is your thoughts on "views" ? Do you think people should avoid using
>> Zend_Db_Table for views, or do you agree with different implementations
>> found on the web where people simply subclass Zend_Db_Table and disable
>> the
>> check on the primary keys?
>
> I cannot disagree with any usage and extension of Zend_Db_Table.
> Ultimately, that is what Zend Framework is all about, providing a great
> set of base & common functionality that developers can harness to build
> out their projects quicker in a more best practices way.
>
> Any time you decide to extend ZF, you should always decide if the
> feature you are implementing by extending is adding a level of
> complexity that is not worth the cost of maintenance and documentation
> on your end. As long as you stay consistent in your extension points,
> and document the design decisions, you should ultimately be fine within
> your own project.
>
> On the subject of views, I think they can definitely be used in
> conjunction with Zend_Db_Table (I can only assume they are for read
> only) as it creates an easy to use object interface into the view itself.
>
> -ralph
>
>
>

Thanks Ralph, I appreciate your thoughts on the matter.

You see, the problem with people extending Zend_Db_Table to disable basic
functionality so that they can use it with a view is, for me, proof that
there's a flaw in Zend_Db_Table. In OOP, you should always extend classes,
not kill functionality. I see overriding methods and not calling the parent
method as bad OOP, breaking the chain and leading to serious design
problems. There are exceptions of course, but I'll be bold and say that in
90% of cases you need to do that, it's because there's a problem in the
underlying design and the problem should be fixed at the root, not with a
hack (overriding without calling the parent).

I'm glad you are open to the idea of adding a base class to Zend_Db_Table
that would decouple relationship functionality. Now, I usually love
criticizing from my "couch", meaning I know quite well it's easy to
criticize a design when you yourself don't contribute to it. I will try to
study Zend_Db_Table a bit over the week-end and come up with my "ideal"
ancestor class, which would allow mapping to a table or view without
relationship requirements.

Another question, when you say decoupling the RowGateway from TabeGateway,
what do you mean? Is there any RowGateway implemention directly in
Zend_Db_Table? I love the word "decoupling" though!!! :-)

--
View this message in context: http://www.nabble.com/Zend_Db_Table-and-primary-keys...-tp25117083p25281608.html
Sent from the Zend DB mailing list archive at Nabble.com.