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


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


9. Class Skeletons



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[

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