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|FLOW3 is a next generation web application framework built for the upcoming TYPO3 v5]). It also invokes the DataMapper (see below). An extension developer uses the Query object to create his own findByFoo() methods for  his Repositories.

3. QueryObjectModel

Deeper and deeper we dig … 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

The Storage Backend translates the Query Object Model in syntactical correct statement (SQL). 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|A class in TYPO3 providing methods to access a database], or [PDO|PHP Data Objects], or your preferred solution.

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 the converted property values). It also resolves relations according to the loading strategy (eg. Lazy Loading Proxy).

Puh! Now we are done. Hope you enjoyed the journey.

F.A.Q

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 will do some extensive profiling sessions, implement Lazy Loading strategies, and strive for optimized Queries.

And please keep in mind: 90% of the work is based on the concepts and code of FLOW3. Credits goes to the FLOW3 team.

1. collect clients’ or personal needs
2. design the relational model (database design)
3. scaffold the extension using the kickstarter
4. add a lot of database queries template handling to the file _pi1, _pi2, _pi3 etc.
5. design the templates

This ends up in an extension design which is hard to maintain – especially for larger projects. A more modern approach uses the Model View Controller Pattern. One of the advantages of this pattern is to enable the developer to focus on the domain of the client (and thus the domain model of the extension). So, the MVC pattern is a prerequisite for Domain Driven Design. This leads to a slightly different development process:

1. collect clients or personal needs
2. design the domain model (classes) translating the domain knowledge of the client into UML
3. scaffolding the extension using a kickstarter
4. adding the business logic to the domain model classes
5. design the templates

What are the pros of this approach

• The developer and the client use a common language.
• The domain model is more decoupled from the implementation architecture.
• It’s clearly defined where the business logic resides (in the domain model classes).

… and the cons

• It adds complexity to the extension.
• It forces the developer to learn new programing paradigms, which might be difficult to schedule in the daily work.

To be consequent we have to go one step further. The domain knowledge is captured in natural language. But natural language is much more expressive than object oriented software design in UML. As a consequence, there is a mismatch between the domain model expressed by the domain experts (the client) and the object oriented model expressed in UML.

If we want to keep all the information of the domain experts we have to define an ontology. To express the domain knowledge in an ontology, OWL seems to be a good solution to me, as it is a W3C standard and targets web applications. To edit ontologies I played around with Protégé.

In the end, we will have a process which can be named “Ontology Driven Extension Development Process”:

1. collect clients or personal needs
2. design the ontology using the same language as the client does
3. scaffolding the extension using a new ontology driven kickstarter
4. adding the business logic to the domain model classes
5. design the templates

What are the pros of this approach

• The developer and the client use a common language.
• The ontology based domain model is independent from the implementation and can be shared across different extensions with different purposes.

… and the cons

• It adds complexity to the development processes.
• It’s forces the developer to learn completely new paradigms an terms.

I’m looking forward to your comments an appreciate any questions.