[TYPO3-ect] Spring and Symfony

[Steve Ryan]

Regarding Object Databases/Object Persistence/Data Access Objects,....

(http://wiki.typo3.org/index.php/Object_Persistence_Framework)

In practical application, save/load on a single table is very limited.
Relationship modeling can help (see Cake or tx_persistence). Ultimately
always writing some queries by hand to leverage from power of sql. Most
software developers have learnt to think about data management in terms
of tables, records and joins. A pure object database doesn't fit the
mechanics of storage.
A good persistence library is a toolkit that makes __some__ commonly
used database features easy. Typically this requires configuring a
persistence class to map it to a database table so that
save/load/delete/search can be implemented in the abstract.

I haven't got my head fully around the IRRE config
(http://wiki.typo3.org/index.php/Inline_Relational_Record_Editing) but
it seems to me that the TCA provides lots of information and structure
to define database relationships. The structure is not so accessible as
is. Only one side of the relationship is linked. On my priority list for
tx_persistence is a function to interpret the TCA into the configuration
style defined by tx_persistence.


I dread per field setters/getter accessor methods.
I'm in favor of the lib approach of  $x->set('fieldname',$value); at
least for "Data Access Objects" because it allows more flexible code and
has less coding overhead.

The inherent documentation provided of the object model can potentially
be moved from class files into TS configuration which I would argue is
more concise and a lot more accessible to update.

There is no need to write a class file for each model in your system.
Making the features that are you can get through class introspection
available for the fields in a Data Access Object allows for example ->

foreach ($this as $field => $value) {echo $value;}

Given that we are using the kickstarter to generate and maintain our
data models, we could easily rewrite class files with per field accessor
functions for the updated model. However software developed to work with
with this model is less flexible because it cannot access object data in
bulk
eg
bulk set/get - tx_lib_object=>overwriteArray($parameters)
or
foreach ($this as $field => $value) {echo $value;}

and so needs to be updated as field lists change.

If you decide to start to maintain the model by hand (no kickstarter),
many files must be updated to add a field. If all the code hangs off a
single configuration array from one file. => single change.

Code generation is not a panacea for write once


I guess I imagine a universal DAO class that is configured with a table
name and a list of fields and relationships. Extension of the base class
to hardcode database meta data is possible.

see
http://syntithenai.com/svn/t3ext/persistence/

It needs a lot of cleaning up but the idea is there and it seems to work.



Stever