Comments on: Wheres the Model in Zend Frameworks MVC? http://www.childofthemachine.com/blog/2008/12/wheres-the-model-in-zend-frameworks-mvc/ Wed, 19 Oct 2011 14:33:17 +0000 hourly 1 http://wordpress.org/?v=3.3 By: Grant Perry http://www.childofthemachine.com/blog/2008/12/wheres-the-model-in-zend-frameworks-mvc/comment-page-1/#comment-75 Grant Perry Wed, 10 Dec 2008 02:32:39 +0000 http://www.grantusmaximus.com/web/?p=68#comment-75 Agree the Model is a rather diverse beast, and one I myself have been a little overwhelmed designing one for my own reuse… For others reading this post I should have mentioned earlier the Zend_Model (http://framework.zend.com/wiki/pages/viewpage.action?pageId=41564) proposal by Jurriën Stutterheim a core contributor from the Zym Framework (http://www.zym-project.com) which coincidently has a Zym_Model (http://code.google.com/p/zym/source/browse) component in the frameworks laboratory similar to the original Zend_Model framework proposal. As mentioned I’ve started work on a Model component for myself and future projects which I hope will address some of the issues/features raising in the discussion on the Zend_Model proposal (but not all since I have a smaller scope than that of a ‘framework’ component)… I’ll share it once I’ve finished if I’m happy with it - although I’m rarely satisfied with my own work ;) Agree the Model is a rather diverse beast, and one I myself have been a little overwhelmed designing one for my own reuse…

For others reading this post I should have mentioned earlier the Zend_Model (http://framework.zend.com/wiki/pages/viewpage.action?pageId=41564) proposal by Jurriën Stutterheim a core contributor from the Zym Framework (http://www.zym-project.com) which coincidently has a Zym_Model (http://code.google.com/p/zym/source/browse) component in the frameworks laboratory similar to the original Zend_Model framework proposal.

As mentioned I’ve started work on a Model component for myself and future projects which I hope will address some of the issues/features raising in the discussion on the Zend_Model proposal (but not all since I have a smaller scope than that of a ‘framework’ component)… I’ll share it once I’ve finished if I’m happy with it – although I’m rarely satisfied with my own work ;)

]]> By: Wil Sinclair http://www.childofthemachine.com/blog/2008/12/wheres-the-model-in-zend-frameworks-mvc/comment-page-1/#comment-72 Wil Sinclair Fri, 05 Dec 2008 18:42:40 +0000 http://www.grantusmaximus.com/web/?p=68#comment-72 This are great ideas to think about. Yes, we will address the problem of models- probably in 1.9. You know, we've probably not stated this part of our philosophy enough. In the Zend Framework project, we typically don't address a problem if it has either of the following 2 aspects: 1) It's already been addressed well in the PHP community, and we don't see any significant value that we can add over existing solutions by building our own. ZF was designed to work well alongside other application components. 2) We don't fully understand the problem and are working with the community to see what people generally want and need. In this case, the second point applies. One might argue that the problem of models is already solved in most- if not all- other MVC frameworks. True, but we're not convinced that we can't do it in a more flexible way yet. The fact is that the M is the hardest thing to abstract in MVC. It is the core of your application and can look very different from application to application. For example, M could be a DB-backed ActiveRecord. But for many people it's backed by a RESTful service. Or CouchDB. Or practically an infinite number of other things. Some people also like to handle forms in the model. Others see them more as a responsibility of the presentation layer. This can also drastically affect where and how validation is performed. Some people like thick controllers, other people like thin. This won't affect the view or controller abstractions significantly, but it might affect models a lot. The issues in the model problem go on and on. The ZF team feels like it has good answers for lots of these problems, but we're not ready to say that we have all the answers yet. So, we've punted on it and took the widely criticized route of not introducing any model abstraction. In essence, ZF doesn't tell you what your models are at all; that's completely up to you. I lot of people see this as an omission- and it is- but hardly a resource-constrained or unintentional omission. That said, we agree with you that there are benefits to be had from a model formalism, especially around forms. Maybe even around the concept of a resource. Please join us on the mailing lists and/or the IRC channels (#zftalk.dev would be the most appropriate for this discussion) and help us think through models to get to the design that will give us a lot of reuse without loosing all the flexibility. Thanks for the feedback! ,Wil This are great ideas to think about. Yes, we will address the problem of models- probably in 1.9.
You know, we’ve probably not stated this part of our philosophy enough. In the Zend Framework project, we typically don’t address a problem if it has either of the following 2 aspects:

1) It’s already been addressed well in the PHP community, and we don’t see any significant value that we can add over existing solutions by building our own. ZF was designed to work well alongside other application components.

2) We don’t fully understand the problem and are working with the community to see what people generally want and need.

In this case, the second point applies. One might argue that the problem of models is already solved in most- if not all- other MVC frameworks. True, but we’re not convinced that we can’t do it in a more flexible way yet.
The fact is that the M is the hardest thing to abstract in MVC. It is the core of your application and can look very different from application to application.
For example, M could be a DB-backed ActiveRecord. But for many people it’s backed by a RESTful service. Or CouchDB. Or practically an infinite number of other things.
Some people also like to handle forms in the model. Others see them more as a responsibility of the presentation layer. This can also drastically affect where and how validation is performed.
Some people like thick controllers, other people like thin. This won’t affect the view or controller abstractions significantly, but it might affect models a lot.
The issues in the model problem go on and on. The ZF team feels like it has good answers for lots of these problems, but we’re not ready to say that we have all the answers yet.
So, we’ve punted on it and took the widely criticized route of not introducing any model abstraction. In essence, ZF doesn’t tell you what your models are at all; that’s completely up to you. I lot of people see this as an omission- and it is- but hardly a resource-constrained or unintentional omission.
That said, we agree with you that there are benefits to be had from a model formalism, especially around forms. Maybe even around the concept of a resource. Please join us on the mailing lists and/or the IRC channels (#zftalk.dev would be the most appropriate for this discussion) and help us think through models to get to the design that will give us a lot of reuse without loosing all the flexibility.

Thanks for the feedback!
,Wil

]]>