In object oriented programming Symfony is a great framework for creating websites and web applications. It is based on MVC (Model-View-Controller) architecture pattern which means that the concerns of a project are separated into three parts.
Model represents the knowledge of the project. It contains functions that manage data and uses the database to manipulate input and output.
View is the visual representation of the model. It’s only job is to get data and display them to the user or to get data from the user and send them to the system.
Controller is the link between the model and the view. It’s responsible for calling the right functions from the Model and the send the data to the right View to be displayed to the user.
This is the main idea behind a Symfony project. Although the business logic is separated by the presentation there are many ways to do it. It’s up to the developer to implement a project using the tools that the framework provides in the most productive way. I will describe the best practice from my point of view.
Model is the most complex part of the three mentioned above.
First comes the implementation of the entities. Entities are classes that describe an object and its attributes. They contain simple functions, mostly getters and setters, and maybe some very simple functions like the ‘canBeDeleted’ that checks if an object can be deleted based on its contents and associations.
After that comes the repositories. The repositories are classes that create the queries and execute them in the database. They are used to return the data needed by using joins and filters in the database tables.
For more complex functions that implement business logic of the project there are the services. Services are classes that contain functions for every logic process that is needed in the execution of any flow of the project. The services use entities and repositories in order to get data, they process them and they return the output.
There are times when business logic is needed in a representation file of the view part. This may be opposite to the MVC pattern but sometimes it is inevitable. In these cases the use of helpers come in very handy. Helpers are classes that are used to keep representation files simple. They are like services but are used exclusively by the representation files of the project.
The two other parts of the MVC pattern are simpler and more clear than the model. The controller is responsible for each flow of the project. It controls the routing and uses all the classes mentioned in the model part. Business logic is mainly implemented in model but there are some cases that simple logic takes place in the controllers. However it is strongly recommended to keep logic away from controllers in order to make the project more readable and maintainable. Finally the view is responsible for the representation of the data to the end user and for collecting the data that the user gives. Most of the times this is it’s only job, but sometimes some logic is needed, so helpers are used.
This is one of the ways a Symfony project can be implemented. As I am concerned it may be the best practice, but even if it’s not.. So what? It works for me for now and until I find an even better one I’ll keep using it.