Web application on Symfony Components, how to?

Question

symfony

Welcome all!
I decided to write a simple web application for user registration and authorization for learning purposes.
The task is to work with third-party libraries and not use frameworks (I write in Yii myself).
There is only bare PHP and Composer.
I began to look at how to solve the following tasks:
1) The application has a FrontController, use routing.
2) Namspaces, autoload of libraries - everything to make it beautiful.
3) Divide the application according to the MVC pattern, attach ORM, template engine for output, use bootstrap for layout, write the User entity with authorization and registration methods.
4) If it is ready to make migrations so that you can deploy the project.
5) Write unit tests and acceptance tests
I read that almost everything can be done using Symfony libraries, well, ok, why not.
Selected libraries:
ClassLoader, HttpKernel, Form, Security, Propel ORM.
Questions:
It seems that there are examples and everything is ok and easy, but still Symfony does not promote MVC and there is no layer such as a model (unlike Yii, for example).
Then how to deal with it? There is a form component for data validation and filling in authorization-registration fields, there is an ORM, but how can I connect both validation and records through ORM to the User object.
How to do it right from the point of view of logic?
Also a question about the template engine, what do you recommend?
I think that for authorization and authentication also use the corresponding components, or is it already too much?

Answer 1

If you really want to understand how to build your bikes, and even more so, bike designers (you are going to use libraries), try Silex. This is a microframework that only has httpkernel, router, Container. It is written in 2 files, chtoli))) so if you figure out how it is implemented there, it will be the biggest experience.
And any connection of the Symfony library, through your ServiceProvider (not ready!) will turn into wonderful evenings spent in the wilds of the code of these same libraries :).
PS. I personally tried everything described above - the result is fire

Answer 2

Divide the application according to the MVC pattern,

Your MVC smoothly turns into MVA and MVA smoothly turns into onion architecture.
Because the model is not a layer, it is an object. One alone (in the context of one request) is ... his task is to take the request and spit out the data. That is, for a controller, a model is a service, for a template, a model is ... entities or DTOs.
A model is ANYTHING that can process data and contain it.
Symfony is a UI framework that just allows you to quickly organize the UI for your application (HTTP API or CLI scripts are just the UI of the application) and therefore how you organize the application architecture is purely your concern. Symphony only provides you with a dependency container to organize the service layer conveniently.
MVC is a useless three letters that say absolutely nothing about how you organize things. MVA is already better and this is exactly what the vast majority of backends have been using for the last 10 years (including RoR), but the concept is the same - separating the data presentation logic from the data processing logic.
How do you do it right or how convenient? How convenient is up to you. You can also write from forms directly in essence anemic, etc. and as you wish. But in essence, the flow should be something like this:
the form component writes data to DTOs (stupid data containers). DTOs go to the service layer where the data is mapped to the entity. Entities (we sang it) ... according to the rule, repositories should be responsible for their safety, and inside you can use anything, but since we have an active record, then all we can do here is just call save in services or suffer ( doctrine in this regard is much more convenient but it has its own problems, and it is also complicated).
But I highly doubt that you will give up the amenities and start doing DTO. Most likely, there will simply be no profit in them for you, they are needed to encapsulate the service layer, that is, so that the UI does not know anything about how the inside is implemented, so that you can change everything whenever you want. Entities are an implementation detail of the service layer, they should never end up in controllers, but sometimes it's convenient. And a good architecture is one that is comfortable to work with in the end (that is, we balance between simplicity and isolation of changes).
I also recommend reading this piece: The Twelve Factors

Answer 3

Add the necessary directories, for example, models, classes, etc., add them to composer.json (if necessary), that's it. Can be used. There are few options for the template engine, either as twig was recommended above, or write your own, or pull it out of existing frameworks, for example, blade from laravel (in my opinion, it’s even pulled out somewhere in composer)