Version 4 by Gavin
on Aug 28, 2006 20:30.

compared with
Current by Ralph Schindler
on Dec 13, 2006 17:16.

Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (39)

View Page History
<p>Let us start with a taxonomy of potential enhancements to Zend_Db_Table/Row/Rowset.</p>

h1. Requirements
<h1>Requirements</h1>

<p>Briefly, for the ZF approach to using modeling objects with data backed by a RDBMS, we'd like to:</p>
# avoid auto-generating any code or configuration files,
<ol>
<li>avoid auto-generating any code or configuration files,</li>
# avoid <li>avoid requiring the developer to write code specific to implementing an ActiveRecord, when the database schema can support a clean mapping of a table's rows to ActiveRecords ( http://www.martinfowler.com/eaaCatalog/activeRecord.html ) <a class="external-link" href="http://www.martinfowler.com/eaaCatalog/activeRecord.html">http://www.martinfowler.com/eaaCatalog/activeRecord.html</a> )</li>
# avoid requiring developers to scatter their "code" across configuration files and PHP source files,
# rely on database introspection,
<li>avoid requiring developers to scatter their &quot;code&quot; across configuration files and PHP source files,</li>
<li>rely on database introspection,</li>
# automatically <li>automatically publish an extensible API providing access to underlying tables that follow naming and structural conventions (similar to most interpretations of ActiveRecord). ActiveRecord).</li>
</ol>

Summary of the ZF's approach:
# Keep it simple! Why? So ZF developers can get their work done quickly with as little pain as possible.
# Solve the 80% first. What? We need to first make the ZF solve the most frequent and common problems frameworks are supposed to solve first.
# Interoperability. Why? The ZF should make extra efforts and smart compromises to create unusually flexible, well-integrated, and "pluggable" components that "play well" with each other, including mixing the use of "ActiveRecord" style access for some tables, and other access styles for other tables.

h1. Investigating Ideas and Alternatives (please contribute)
<p>Summary of the ZF's approach:</p>
<ol>
<li>Keep it simple! Why? So ZF developers can get their work done quickly with as little pain as possible.</li>
<li>Solve the 80% first. What? We need to first make the ZF solve the most frequent and common problems frameworks are supposed to solve first.</li>
<li>Interoperability. Why? The ZF should make extra efforts and smart compromises to create unusually flexible, well-integrated, and &quot;pluggable&quot; components that &quot;play well&quot; with each other, including mixing the use of &quot;ActiveRecord&quot; style access for some tables, and other access styles for other tables.</li>
</ol>

We are experimenting with mixing ActiveRecord and DAO patterns, as the latter better accommodate more complex object modeling needs when the underlying schema doesn't quite fit the desired object domain patterns.

Ok, so how does all that answer the question that was asked? I needed a little context and common understanding of terminology first ...
<h1>Investigating Ideas and Alternatives (please contribute)</h1>

If the ZF supports an interpretation of ActiveRecord, yet allows some flexibility with DAO-like capabilities, then a ZF developer could design by creating an object domain and a supporting schema, relying on ActiveRecord-style tables/classes when there is naturally a close correspondence between tables and desired classes, but fall back to one of the other ZF mechanisms for working with other situations, all within the same application. Hint: Debate, suggestions, feedback, opinions,
and more are most welcome.
<p>We are experimenting with mixing ActiveRecord and DAO patterns, as the latter better accommodate more complex object modeling needs when the underlying schema doesn't quite fit the desired object domain patterns.</p>

h2. ORM Mapping
<p>Ok, so how does all that answer the question that was asked? I needed a little context and common understanding of terminology first ...</p>

Mappers live outside of the object model domain and database schema. They map the model domain onto a database schema. For non-trivial domain models, the underlying auto-generated database schema resulting can be quite complex. If not auto-generated / synchronized / maintained, then the effort required to specify, maintain, and enhance the configuration information (e.g. like propel) throughout an application's life cycle does not seem to fit the ZF's approach to solving the stated goals.
<p>If the ZF supports an interpretation of ActiveRecord, yet allows some flexibility with DAO-like capabilities, then a ZF developer could design by creating an object domain and a supporting schema, relying on ActiveRecord-style tables/classes when there is naturally a close correspondence between tables and desired classes, but fall back to one of the other ZF mechanisms for working with other situations, all within the same application. Hint: Debate, suggestions, feedback, opinions, <br />
and more are most welcome.</p>

I found this person's experience ( http://www.kuro5hin.org/story/2006/3/11/1001/81803 ) with an ORM mapper roughly consistent with my experiences, including difficult to optimize inefficiencies arising from numerous SQL queries with overlapping result sets. Although long, the blog entry doesn't require the reader to possess a deep past experience with Java or ORMs, and uses humor to keep the read entertaining.
<h2>ORM Mapping</h2>

* http://www.martinfowler.com/eaaCatalog/dataMapper.html
<p>Mappers live outside of the object model domain and database schema. They map the model domain onto a database schema. For non-trivial domain models, the underlying auto-generated database schema resulting can be quite complex. If not auto-generated / synchronized / maintained, then the effort required to specify, maintain, and enhance the configuration information (e.g. like propel) throughout an application's life cycle does not seem to fit the ZF's approach to solving the stated goals.</p>

h2. ORM Wrapping
<p>I found this person's experience ( <a class="external-link" href="http://www.kuro5hin.org/story/2006/3/11/1001/81803">http://www.kuro5hin.org/story/2006/3/11/1001/81803</a> ) with an ORM mapper roughly consistent with my experiences, including difficult to optimize inefficiencies arising from numerous SQL queries with overlapping result sets. Although long, the blog entry doesn't require the reader to possess a deep past experience with Java or ORMs, and uses humor to keep the read entertaining.</p>

Wrapping solutions encapsulate database complexities and SQL code to provide simpler API's for retrieving and modifying the data store. The API's abstract the database schema, and the resulting, exposed model of data in the data store does not always match the desired object model domain. However, when a database schema closely parallels the object model domain (e.g. tables <==> classes), wrapping might yield excellent results. Regardless, the "model" part of MVC can be used to process results retrieved from a wrapping API into models fitting the business logic.
<ul>
<li><a class="external-link" href="http://www.martinfowler.com/eaaCatalog/dataMapper.html">http://www.martinfowler.com/eaaCatalog/dataMapper.html</a></li>
</ul>

* [Overview of Ruby's interpretation|http://www-128.ibm.com/developerworks/java/library/j-cb03076/?ca=dgr-lnxw01ActiveRecord]
* http://www.martinfowler.com/eaaCatalog/tableDataGateway.html
* http://www.martinfowler.com/eaaCatalog/rowDataGateway.html
* http://www.martinfowler.com/eaaCatalog/activeRecord.html
* [Java/Sun-centric interpretation of DAO|http://java.sun.com/blueprints/patterns/DAO.html]

Using a framework, much/most of the business logic does not need to reside in DAOs, and can reside in classes that work with the data abstractions created by the DAOs. DAOs can provide a type of manual mapping of schemas to objects and vice-versa, such that objects need not exactly resemble the underlying schema (e.g. Class 1-to-1 Table). Thus, I consider DAO as something not identical to either the ORM mapping or Active-Record style wrapping approaches.
<h2>ORM Wrapping</h2>

<p>Wrapping solutions encapsulate database complexities and SQL code to provide simpler API's for retrieving and modifying the data store. The API's abstract the database schema, and the resulting, exposed model of data in the data store does not always match the desired object model domain. However, when a database schema closely parallels the object model domain (e.g. tables &lt;==&gt; classes), wrapping might yield excellent results. Regardless, the &quot;model&quot; part of MVC can be used to process results retrieved from a wrapping API into models fitting the business logic.</p>

h1. Examples
<ul>
<li><a href="http://www-128.ibm.com/developerworks/java/library/j-cb03076/?ca=dgr-lnxw01ActiveRecord">Overview of Ruby's interpretation</a></li>
<li><a class="external-link" href="http://www.martinfowler.com/eaaCatalog/tableDataGateway.html">http://www.martinfowler.com/eaaCatalog/tableDataGateway.html</a></li>
<li><a class="external-link" href="http://www.martinfowler.com/eaaCatalog/rowDataGateway.html">http://www.martinfowler.com/eaaCatalog/rowDataGateway.html</a></li>
<li><a class="external-link" href="http://www.martinfowler.com/eaaCatalog/activeRecord.html">http://www.martinfowler.com/eaaCatalog/activeRecord.html</a></li>
<li><a href="http://java.sun.com/blueprints/patterns/DAO.html">Java/Sun-centric interpretation of DAO</a></li>
</ul>

* [Zend_Db_Table with table-specific row objects|http://framework.zend.com/issues/browse/ZF-38]
* [KISS ORM|http://www.nabble.com/-need-advices--An-idea-to-build-a-KISS-ORM-system-upon-Zend_Db_Table-tf1926214.html#a5274924]
* [eZeAR_ActiveRecord|http://blog.wolff-hamburg.de/archives/3-eZeAR_ActiveRecord-implementation.html]

<p>Using a framework, much/most of the business logic does not need to reside in DAOs, and can reside in classes that work with the data abstractions created by the DAOs. DAOs can provide a type of manual mapping of schemas to objects and vice-versa, such that objects need not exactly resemble the underlying schema (e.g. Class 1-to-1 Table). Thus, I consider DAO as something not identical to either the ORM mapping or Active-Record style wrapping approaches.</p>


<h1>Examples</h1>

<ul>
<li><a href="http://framework.zend.com/issues/browse/ZF-38">Zend_Db_Table with table-specific row objects</a></li>
<li><a href="http://www.nabble.com/-need-advices--An-idea-to-build-a-KISS-ORM-system-upon-Zend_Db_Table-tf1926214.html#a5274924">KISS ORM</a></li>
<li><a href="http://blog.wolff-hamburg.de/archives/3-eZeAR_ActiveRecord-implementation.html">eZeAR_ActiveRecord</a></li>
<li><ac:link><ri:user ri:username="ralph" /></ac:link>'s <strong><a href="http://www.activemodel.org/wiki/index.php/Main_Page">ActiveModel</a></strong></li>
</ul>