Added by Kevin Truong, last edited by Wil Sinclair on Sep 28, 2006  (view change)

Labels

 
(None)

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: 14)

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

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

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.

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

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

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.

A Zend_Model with support for multiple backend seems to me a good idea, and will review the proposal to adapt it to this.

The use of public properties, although I recognize that is more intuitive, does not follow the standards of the object-oriented programming.
In addition, the use of global properties does not allow the extension of Zend_Model_Field to make things like for example:

About the assignPostVars method, uses Zend_Filter for the validation of the data introduced in the form.
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.

What about $user->dateValue($user->id, '%Y');

I had imagined you would be overloading properties to achieve this, so you could certainly extend the class without too much effort.

E.g. $user->id->dateValue('%Y'); // functionally identical to your example but using overloading.

I have created a new revision using public properties, eliminating the part of validation of data and added objects loaded dynamically.

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.

I can't tell if this conversation is over, but I thought I'd add this anyway.
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.

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.

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.

Posted by Uros at Aug 20, 2006 04:13

Hello,

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<>CSV, DB<>SOAP or what you exactly want.

Source of my framework is closed now, but if you want I can release code somewhere.

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?

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