[TYPO3-mvc] The different layers of persistence

Ernesto Baschny [cron IT] ernst at cron-it.de
Wed Jul 15 11:26:13 CEST 2009


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
> 


More information about the TYPO3-project-typo3v4mvc mailing list