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
7. Class Index
- Zend_Db_Model
- Zend_Db_Model_Exception
8. Use Cases
| UC-01 |
|---|
| UC-02 |
|---|
9. Class Skeletons
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.
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.
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? ![]()
ZF Home Page
Code Browser
Wiki Dashboard
Shouldn't it be Zend_Model_DB? So that later on we could have Zend_Model_XML... ?