Book Image

Mastering Symfony

Book Image

Mastering Symfony

Overview of this book

In this book, you will learn some lesser known aspects of development with Symfony, and you will see how to use Symfony as a framework to create reliable and effective applications. You might have developed some impressive PHP libraries in other projects, but what is the point when your library is tied to one particular project? With Symfony, you can turn your code into a service and reuse it in other projects. This book starts with Symfony concepts such as bundles, routing, twig, doctrine, and more, taking you through the request/response life cycle. You will then proceed to set up development, test, and deployment environments in AWS. Then you will create reliable projects using Behat and Mink, and design business logic, cover authentication, and authorization steps in a security checking process. You will be walked through concepts such as DependencyInjection, service containers, and services, and go through steps to create customized commands for Symfony's console. Finally, the book covers performance optimization and the use of Varnish and Memcached in our project, and you are treated with the creation of database agnostic bundles and best practices.
Table of Contents (17 chapters)
Mastering Symfony
Credits
About the Author
About the Reviewers
Index

Choosing between creating a Model or entity


The common mistake among some Symfony developers is that they think an entity is a Model or, even worse, it can be modified to look like a Model. I have seen entities that consist of a bunch of traits and services are injected into some of them. The end result is bulky code, which is hard to maintain and very slow to run.

Adding extra features to an entity is a bad practice. Keep entities as a data-persistence layer and, if you need a Model, create one. There, you can inject the services if you have to.

You might notice some third-party bundles such as FOSUserBundle have another folder called Model and keep objects similar to entities here. They also have extra code, usually called managers, to take care of additional needs and injecting other services.

As a general rule, if you are happy with Doctrine, then use entities. However, if you want your bundle be independent of any persistence layer and have extra features and services injected into your...