<p>I think the 'DB' should be dropped altogether. A model, whilst usually tied to a database in some form, describes a behaviour of an object and shouldn't necessarily be associated too closely with a specific implementation.</p>
<p>I'd be happier with a Zend_Model that accepts a DB backend (be it Pdo_Mysql, XML or whatever). That way you could remove a lot of the 'table', 'adapter' methods and concentrate more on performing more abstract tasks like 'insert', 'update' or 'find'.</p>
<p>I think using the public properties of a Zend_Model would also be more intuitive than a 'field()' method. To me, $user->id = 1 is a lot less complicated and easier to understand than $user->field('id')->value(1);</p>
<p>I would also review methods like 'assignPostVars' which would seem to bypass the recommended filtering processes and also may be too specific - see the current component Zend_Filter_Input which does a good job of pre-filtering before you pass values to your model.</p>
<p>A Zend_Model with support for multiple backend seems to me a good idea, and will review the proposal to adapt it to this. </p>
<p>The use of public properties, although I recognize that is more intuitive, does not follow the standards of the object-oriented programming. <br />
In addition, the use of global properties does not allow the extension of Zend_Model_Field to make things like for example: </p>
<p>About the assignPostVars method, uses Zend_Filter for the validation of the data introduced in the form. <br />
In this moment there are other proposals, that are centered specifically in the validation of forms and could be a perfect replacement for this method.</p>
<p>I have created a new revision using public properties, eliminating the part of validation of data and added objects loaded dynamically. </p>
<p>I have studied the use of multiple backends, but it has seemed to me that it adds excessive complexity to Zend_Db_Model, and that is not the reason for this proposal.</p>
<p>I can't tell if this conversation is over, but I thought I'd add this anyway.<br />
About the comments about different storage for Model data, I think it would be better to separate the storage from the model class, ie have a ModelLoader/ModelMapper class hierachy that deal with creating an Model from a data source (DB/xml/whatever), and saving the model's data back to that medium. So there would be a Zend_Model_Mapper interface class and one or more concrete implementations for each Model implementation. </p>
<p>As well as separating the Model from a particular data source it also separates the Model creation code from the model behavioral code, which I think is a good aim as well.</p>
<p>I also like the idea of separating storage from model class. I'm using propel most of the time and I found many problems because of storage dependency.</p>
<p>I have already done storage and model separation in my own framework. I think this is very good idea and missing in ZendFramework. By using DataAdaptors you can read and write to different datasources, ie. DB<<span style="text-decoration: line-through;">>CSV, DB<</span>>SOAP or what you exactly want.</p>
<p>Source of my framework is closed now, but if you want I can release code somewhere.</p>
<p>At my company we will develop brand new project using Zend Framework, and DataAdaptor`s functionality is what we need. Also we want to implement IOC Factory. Maybe our work will be helpful for Zend Community. What do you think? <ac:emoticon ac:name="smile" /></p>
9 Comments
comments.show.hideJul 16, 2006
Kevin Truong
<p>Shouldn't it be Zend_Model_DB? So that later on we could have Zend_Model_XML... ?</p>
Jul 16, 2006
Simon Mundy
<p>I think the 'DB' should be dropped altogether. A model, whilst usually tied to a database in some form, describes a behaviour of an object and shouldn't necessarily be associated too closely with a specific implementation.</p>
<p>I'd be happier with a Zend_Model that accepts a DB backend (be it Pdo_Mysql, XML or whatever). That way you could remove a lot of the 'table', 'adapter' methods and concentrate more on performing more abstract tasks like 'insert', 'update' or 'find'.</p>
<p>I think using the public properties of a Zend_Model would also be more intuitive than a 'field()' method. To me, $user->id = 1 is a lot less complicated and easier to understand than $user->field('id')->value(1);</p>
<p>I would also review methods like 'assignPostVars' which would seem to bypass the recommended filtering processes and also may be too specific - see the current component Zend_Filter_Input which does a good job of pre-filtering before you pass values to your model.</p>
Jul 17, 2006
Borja Fernandez
<p>A Zend_Model with support for multiple backend seems to me a good idea, and will review the proposal to adapt it to this. </p>
<p>The use of public properties, although I recognize that is more intuitive, does not follow the standards of the object-oriented programming. <br />
In addition, the use of global properties does not allow the extension of Zend_Model_Field to make things like for example: </p>
<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
$user->field('date')->dateValue('%Y');
]]></ac:plain-text-body></ac:macro>
<p>About the assignPostVars method, uses Zend_Filter for the validation of the data introduced in the form. <br />
In this moment there are other proposals, that are centered specifically in the validation of forms and could be a perfect replacement for this method.</p>
Jul 17, 2006
Simon Mundy
<p>What about $user->dateValue($user->id, '%Y');</p>
<p>I had imagined you would be overloading properties to achieve this, so you could certainly extend the class without too much effort.</p>
<p>E.g. $user->id->dateValue('%Y'); // functionally identical to your example but using overloading.</p>
Jul 19, 2006
Borja Fernandez
<p>I have created a new revision using public properties, eliminating the part of validation of data and added objects loaded dynamically. </p>
<p>I have studied the use of multiple backends, but it has seemed to me that it adds excessive complexity to Zend_Db_Model, and that is not the reason for this proposal.</p>
Aug 09, 2006
tim rodger
<p>I can't tell if this conversation is over, but I thought I'd add this anyway.<br />
About the comments about different storage for Model data, I think it would be better to separate the storage from the model class, ie have a ModelLoader/ModelMapper class hierachy that deal with creating an Model from a data source (DB/xml/whatever), and saving the model's data back to that medium. So there would be a Zend_Model_Mapper interface class and one or more concrete implementations for each Model implementation. </p>
<p>As well as separating the Model from a particular data source it also separates the Model creation code from the model behavioral code, which I think is a good aim as well.</p>
Aug 20, 2006
Uros
<p>I also like the idea of separating storage from model class. I'm using propel most of the time and I found many problems because of storage dependency.</p>
Nov 06, 2006
Marcin Nowak
<p>Hello,</p>
<p>I have already done storage and model separation in my own framework. I think this is very good idea and missing in ZendFramework. By using DataAdaptors you can read and write to different datasources, ie. DB<<span style="text-decoration: line-through;">>CSV, DB<</span>>SOAP or what you exactly want.</p>
<p>Source of my framework is closed now, but if you want I can release code somewhere.</p>
<p>At my company we will develop brand new project using Zend Framework, and DataAdaptor`s functionality is what we need. Also we want to implement IOC Factory. Maybe our work will be helpful for Zend Community. What do you think? <ac:emoticon ac:name="smile" /></p>
Nov 06, 2006
Marcin Nowak
<p>Correct: datasources, ie. DB < - > CSV, DB < - > SOAP</p>