How to split a Symfony2 application into backend and frontend?

Question

symfony

I am slowly moving from Yii1 to Symfony2.
In Yii, an application could be divided into back- and frontend in two ways: splitting into two applications (folders common, frontend and backend) with their own entry points (frontend/web/index.php and backend/web/index.php) and adding a module backend.
I'm interested in three questions:
1) What are the ways in Symfony2?
2) How to use bundles correctly? Let's say I'm making an online store with the usual functionality (users with registration, products, orders, etc. + admin panel). What will be the bundles then?
3) What is this Acme folder in src? Or rather, I know what Acme Corporation is and Acme is a fictitious name for an example, but why are all the bundles in this folder? How should it be called in a real project?

Answer 1

1) are all the same. Splitting the application into two separate ones (you can do it through one entry point and use the URL-map middleware to resolve different applications by urls. You can split it into bundles - FrontendBundle / BackendBundle. This option is a little less flexible, just like in the case of modules in Yii. Although you can live. Personally, I tried the option with full separation only once, because the logic of the backend and front end and application settings were too different. Yes, and initially the Symfony developers planned that people would do this, but the approach with bundles has become more popular
. I can say that taking out general application settings, common parts, etc. is a little easier with Symfony.
2) Bundles must be self-sufficient. Basically, they are modules. If you do not plan to reuse the code in other projects, then there is no point in putting this code into a separate bundle. In 99% of cases, there is no sense in the difference between the business logic of the application for different bundles.
Usually they do some kind of CoreBundle / SiteBundle / AppBundle or something like that and they do all the project logic there. If some functionality appears that can be reused (for example, an abstraction layer for working with payment systems, a notification system, or something else), this business can be put into a separate bundle and subsequently reused.
It is also a fairly common practice to store code simply in the namespace of the project, and store only Symfony-specific things in bundles (service registration, validator settings, database mapping, etc., that is, everything that Symfony needs). This project structure often comes up when talking about DDD, and it's actually easier to keep the project clean this way. If you also have controllers defined as services, then it’s generally beautiful. But this is all to weaken the connection between your project code and the framework.
3) This is a namespace. Usually, instead of Acme, they write either the name of the project or the name of the contractor's company / freelancer's nickname ...
Most people are confused by the need to store code one level down. Let's say you have only one namespace, the code is all in it, what's the point in keeping one single folder in the src folder? So they came up with the PSR-4 standard, which allows you to specify a prefix. For example, to get rid of the Acme folder, all its contents can be dragged to a higher level (directly to src), and in composer.json write

"autoload": {
    "psr-4": {"Acme\\": "src/"}
}

It's all purely a matter of namespaces and autoload settings.

Answer 2

/src/Project/Controller/
/src/Project/Controller/Api/*Controller.php
/src/Project/Controller/Backend/*Controller.php
/src/Project/Controller/Frontend/*Controller.php
We have something like this implemented the division of the project, the bundle is one. Everything except controllers lies in their directories without separation.
Design in app/Resource/view is also divided into BackEnd, FrontEnd. At the root of the view are general things, macros, forms, the base layer.