Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Zend_Db_Model Component Proposal

Proposed Component Name Zend_Db_Model
Developer Notes http://framework.zend.com/wiki/display/ZFDEV/Zend_Db_Model
Proposers Borja Fernandez
Revision 1.2 - 19 July 2006: Updated from community comments. (wiki revision: 15)

Table of Contents

1. Overview

An object that wraps a row in a database table or view, encapsulates the database access, and allows to adds domain logic on that data.

2. References

*

3. Component Requirements, Constraints, and Acceptance Criteria

none

4. Dependencies on Other Framework Components

  • Zend_Db
  • Zend_Exception

5. Theory of Operation

Define a Class based on Zend_Db_Model_Abstract and add your own domain logic.

6. Milestones / Tasks

zone: Missing {zone-data:milestones}

7. Class Index

  • Zend_Db_Model
  • Zend_Db_Model_Exception

8. Use Cases

UC-01
UC-02

9. Class Skeletons

]]></ac:plain-text-body></ac:macro>

]]></ac:plain-text-body></ac:macro>

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jul 16, 2006

    <p>Shouldn't it be Zend_Model_DB? So that later on we could have Zend_Model_XML... ?</p>

  2. Jul 16, 2006

    <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>

    1. Jul 17, 2006

      <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>

      1. Jul 17, 2006

        <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>

  3. Jul 19, 2006

    <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>

  4. Aug 09, 2006

    <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>

  5. Aug 20, 2006

    <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>

  6. Nov 06, 2006

    <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>

    1. Nov 06, 2006

      <p>Correct: datasources, ie. DB < - > CSV, DB < - > SOAP</p>