[TYPO3-mvc] The different layers of persistence

[Jochen Rau]

Hi.

I have posted this on http://blog.typoplanet.de now.

Jochen

Ernesto Baschny [cron IT] wrote:
> Hi Jochen,
>
> nice overview! Also a good candidate for a blog entry in "buzz"!
>
> Cheers,
> Ernesto
>
> Jochen Rau schrieb:
>> Hi.
>>
>> I just want to give you some hints what the different classes and
>> (sub)layers of the persistence layers are responsible for. This should
>> enable you to dig more easily into the system (and report bugs ;-)).
>>
>> Let's begin from the top level
>>
>> 1. Repository
>> A Repository is the first objects a developer comes in contact to. It
>> handles only domain objects and provide task oriented interface to
>> retrieve them by saying findByFoo('Bar'). Most of the time you are done.
>>
>> 2. Query
>> The next level is the Query object. It provides methods to create an
>> abstract query (abstract in sense of abstracted from where the objects
>> come from). It has no clue about the underlying structure of the
>> storage. It even does not now if it is based on a relational model or a
>> tree model (like the content repository of FLOW3). It also invokes the
>> DataMapper (see below). An extension developer uses the Query object to
>> create his own findByFoo() methods.
>>
>> 3. QueryObjectModel
>> Deeper and deeper ... In comparison to the Query object Query Object
>> Model knows about the underlying concepts of relations and thus Joins
>> and Orderings. An extension developer may use this class to specify more
>> complex and "relational model" aware queries. That makes the creation of
>> queries (esp. Joins) al little bit laborious. But it helps to keep
>> abstraction.
>>
>> 4. StorageBackend (aka Typo3DbBackend)
>> The Storage Backend translates the Query Object Model in syntactical
>> correct SQL (hopefully ;-)). It also invokes the call to the database
>> via a handler. An extension developer normally does not have to mak his
>> hands dirty with SQL (which is in most cases the best way to improve
>> performance and security ;-) ).
>>
>> 5. DatabaseHandler
>> The Database Handler prepares queries, fetches the result set. It can be
>> simply the t3lib_db or PDO or ...
>>
>> 6. DataMapper
>> And finally the Data Mapper. It maps the resulting rows on the Domain
>> Object (it creates an empty object and fills it with properties). It
>> also resolves relations according to the loading strategy (eg. Lazy
>> Loading).
>>
>> Puh! Now we are done. Hope you enjoyed the journey.
>>
>> FAQ
>> Q: Are you nuts! Six different layers, dozens of objects, and bunch of
>> new things to learn! I only wanted to say "SELECT * FROM Tx_MyExt_Foo
>> WHERE ..."!
>> A: You are right: I'am nuts (at least a litte bit ;-)). But now we are
>> fully compatible to the (Query) API of FLOW3 and reached the best level
>> to port Extensions forward. And I really like the Idea of having totally
>> freedom of choice.
>> Q: And what about performance?
>> A: That’s indeed a very important point. We are trying our best to meet
>> the goals (see also http://forge.typo3.org/issues/show/3876)
>>
>> And please keep in mind: 90% of the work is based on the concepts and
>> code of FLOW3. Credits goes to the FLOW3 team.
>>
>> Regards
>> Jochen
>>

-- 
Every nit picked is a bug fixed