TYPO3 v8 has reached its end-of-life March 31st, 2020 and is not maintained by the community anymore. Looking for a stable version? Use the version switch on the top left.
You can order Extended Long Term Support (ELTS) here: TYPO3 ELTS.
Model-View-Controller in Extbase¶
Object-oriented programming and Domain-Driven Design specify a structure for our Extension on different levels. Object-oriented programming provides us with the basic building blocks of software development: Objects as combination of data and associated methods. Domain Driven Design provides us tools for creating a Model that represents the real world rules in Software. However, we still lack a component that specifies how to react on user requests and what functionality the application will ultimately have. The Model View Controller Paradigm provides us exactly that. It ensures a clean separation of the Domain Model from the View. This clean Separation is the foundation of the smooth interaction between Extbase and Fluid
The Model-View-Controller design pattern is the infrastructure that we build our application on. It provides us a rough roadmap and the separation of the presentation logic from the Model.
The MVC pattern divides our application into three rough layers: the Model, which implements the Domain Model including the domain logic, the controller, which controls the flow of the application, and the view, which prepares and outputs the data to the user (see Figure 2-4).
The lowest layer, the Model encapsulates the application logic and data as well as the according access and storage logic. Domain Driven Design divides this layer even further. In a Extbase extension you can find the classes for this layer in the folder Classes/Domain.
The Controller presents externally ( that is: directly callable by the user ) functionality. It coordinates the interaction of Model and View to dispatch the actual request. It fetches Data from the Model and hands it to the View for presentation. Important: The Controller only coordinates, the actual functionality is usually implemented in the Model. Because the Controller is difficult to test, it should stay as slim as possible.
The top layer, the View encapsulates the whole Presentation Logic and everything related with the presentation of data.
The Interaction of Model, View and Controller¶
The Functionality of many Applications can be split into modules. This modules can be further differentiated. The Functionality of a Blog e.g. can be split as follows:
Functionality related to Blog Posts:
List View of all Blog-Posts
Create a Blog-Post
Show a Blog-Post
Edit a Blog-Post
Delete a Blog-Post
Functionality related to Comments:
These Modules are implemented in a Controller. Inside of this Controller there is a Action for every single function. In the above example we have a PostController, which implements the Actions to create, show, edit and delete Posts. In Addition there is a CommentController, which implements the Actions to create and delete Comments.
The Listing of Comments is not implemented as separate Action here, as the Comments usually should be display directly with the Blog-Post and there is no View showing all Comments.
Both Examples show that a Controller is mainly a Container for associated Actions.
Now we show by example how Model, View and Controller work together. The first request we look at should display a list of blog posts (see Figure 2-5):
The User sends a request (1). The request Object contains information about the controller
and action that should be called and optionally additional parameters. In this example the
Post and the action
To respond to the request the action has to query certain data from the Model.(2) In return it receives on or several domain Objects. In our example the action queries all blog posts and receives a array with all Blog-Post Objects as response.(3)
Thereafter the action calls the according view and hands over the data for presentation (4) - the array with Blog-Posts in our case.
The View displays the data and returns the Response to the user.(5)
Now as the first request is completely dispatched the user has a list of all Blog-Posts displayed in the browser. Now the user clicks on a single Blog-Post and gets the complete blog post. In addition the user can add a comment to this post. With the help of Figure 2-6 we want to understand how the comment is stored.
When submitting the comment form the user creates a new request (1)
containing the according controller and action. In our example the controller is
Comment and the action is
new. Furthermore the request
contains the comment text and a reference to the commented Blog-Post.
The called action now has to modify the Model and add the new comment to the according Blog-Post. (2)
After that the action forwards to another action (3). In our case we forward
show-Action in the
which displays the Blog-Post and the freshly added comment.
show-Action calls the according view and hands
over the Blog-Post that should be displayed. (4)
The view now displays the data and returns the result to the user. (5)
You will often see that actions can be sorted into two categories: Some actions control the display of a Model, while other actions modify the Model and usually forward to displaying actions. In the above example we first saw a displaying action and then a modifying action.
Now we have all the Modules we need for developing our Application. You got to know the Object-oriented basics, modeled the application domain with Domain Driven Design and introduced the clean separation between the Domain Model and the Presentation Logic
At last we want to introduce you to a development Model that can drastically improve the stability and quality of the source code: Test-Driven Development. This approach can be used independently of the previously introduced concepts, but is another helpful Module for the extension development with Extbase and Fluid.