> 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
没有评论:
发表评论