Although the questions were asked in a general context, I'll answer in
the context of ZF.
Briefly, for the ZF approach to using modeling objects with data backed
by a RDBMS, we'd like to:
- avoid auto-generating any code or configuration files,
- 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 )
- avoid requiring developers to scatter their "code" across
configuration files and PHP source files,
- rely on database introspection,
- automatically publish an extensible API providing access to underlying
tables that follow naming and structural conventions (similar to most
interpretations of ActiveRecord).
My quick summary of the ZF's approach to achieving its goals (
http://framework.zend.com/roadmap ):
- 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.
I'm also 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 ...
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.
Alternative 1 (Mapping)
=====================
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 (
http://framework.zend.com/roadmap ).
I found this person's experience (
http://www.kuro5hin.org/story/2006/3/11/1001/81803 ) with alternative
(1) roughly consistent with my experiences. 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.
Alternative 2 (Wrapping)
=====================
ActiveRecord.
Overview of Ruby's interpretation:
-
http://www-128.ibm.com/developerworks/java/library/j-cb03076/?ca=dgr-lnxw01ActiveRecordAlternative 3 (DAO)
=====================
A Java/Sun-centric interpretation of DAO:
-
http://java.sun.com/blueprints/patterns/DAO.htmlUsing 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.
Cheers,
Gavin
Ralph Schindler wrote:
> Survey - The topic of scaffolding.
>
> When it comes to modeling objects to database records, which does
> everyone prefer in the design stage:
>
>
>
>
> 1) creating a meta file in a pseudo-language or xml (like propel) that
> will then be used by a program to generate objects as well as create
> the database structure?
>
> - or -
>
> 2) create a database structure, then run a program that will read the
> schema and create objects based off of what it found.
>
>
>
> -ralph
>
>