Organizing Your Business Logic

In computer software, business logic or domain logic is "the part of the
program that encodes the real-world business rules that determine how data can
be created, displayed, stored, and changed" (read full definition).

In Symfony applications, business logic is all the custom code you write for
your app that's not specific to the framework (e.g. routing and controllers).
Domain classes, Doctrine entities and regular PHP classes that are used as
services are good examples of business logic.

For most projects, you should store everything inside the AppBundle.
Inside here, you can create whatever directories you want to organize things:

The recommended approach of using the AppBundle/ directory is for
simplicity. If you're advanced enough to know what needs to live in
a bundle and what can live outside of one, then feel free to do that.

Traditionally, the naming convention for a service was a short, but unique
snake case key - e.g. app.utils.slugger. But for most services, you should now
use the class name.

Best Practice

Best Practice

The id of your application's services should be equal to their class name,
except when you have multiple services configured for the same class (in that
case, use a snake case id).

Now you can use the custom slugger in any controller class, such as the
AdminController:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

useAppBundle\Utils\Slugger;publicfunctioncreateAction(Request$request,Slugger$slugger){// ...// you can also fetch a public service like this// but fetching services in this way is not considered a best practice// $slugger = $this->get('app.slugger');if($form->isSubmitted()&&$form->isValid()){$slug=$slugger->slugify($post->getTitle());$post->setSlug($slug);// ...}}

This is controversial, and in our experience, YAML and XML usage is evenly
distributed among developers, with a slight preference towards YAML.
Both formats have the same performance, so this is ultimately a matter of
personal taste.

We recommend YAML because it's friendly to newcomers and concise. You can
of course use whatever format you like.

You may have noticed that the previous service definition doesn't configure
the class namespace as a parameter:

1
2
3
4
5
6
7
8
9

# app/config/services.yml# service definition with class namespace as parameterparameters:slugger.class:AppBundle\Utils\Sluggerservices:app.slugger:class:'%slugger.class%'

This practice is cumbersome and completely unnecessary for your own services.

Best Practice

Best Practice

Don't define parameters for the classes of your services.

This practice was wrongly adopted from third-party bundles. When Symfony
introduced its service container, some developers used this technique to easily
allow overriding services. However, overriding a service by just changing its
class name is a very rare use case because, frequently, the new service has
different constructor arguments.

Symfony is an HTTP framework that only cares about generating an HTTP response
for each HTTP request. That's why Symfony doesn't provide a way to talk to
a persistence layer (e.g. database, external API). You can choose whatever
library or strategy you want for this.

In practice, many Symfony applications rely on the independent
Doctrine project to define their model using entities and repositories.
Just like with business logic, we recommend storing Doctrine entities in the
AppBundle.

The three entities defined by our sample blog application are a good example:

Doctrine entities are plain PHP objects that you store in some "database".
Doctrine only knows about your entities through the mapping metadata configured
for your model classes. Doctrine supports four metadata formats: YAML, XML,
PHP and annotations.

Best Practice

Best Practice

Use annotations to define the mapping information of the Doctrine entities.

Annotations are by far the most convenient and agile way of setting up and
looking for mapping information:

The Symfony source code follows the PSR-1 and PSR-2 coding standards that
were defined by the PHP community. You can learn more about
the Symfony Coding standards and even
use the PHP-CS-Fixer, which is a command-line utility that can fix the
coding standards of an entire codebase in a matter of seconds.