What is the equivalent of a repository for writing tasks in doctrine?

Question

As the API of Doctrine says:

An EntityRepository serves as a repository for entities with generic as well as business specific methods for retrieving entities.

This class is designed for inheritance and users can subclass this class to write their own repositories with business-specific methods to locate entities.

But where is the right place to put my business-logic for saving entities?

1. Putting right constructors in my entity itself?
2. Putting it also into the Repository?
3. Inserting an new entity is very related to the "form" which made it possible to enter the data, so it should be more or less in the controller?
4. Making a helper-class for the controller so that the work is done by the helper class and not blowing up my controller?
5. Anything else i did not come in mind while writing this question?

I prefer a solution far away from blowing up my controller. Currently i made a helper class which is called by different controllers, because I'm not really sure where to put it.

Answer 1

My solution is to use a layer of managers like UserManager, ArticleManager, etc. This layer is the implementation of the Service Layer pattern.

The managers layer hides everything related to persisting and fetching model objects — that is, objects using this layer don't care how and where models are stored and it can be changed at any time without having to rewrite the whole application.

So, for example, controllers know nothing about Doctrine. I might be using Doctrine ORM today for persistence, but tomorrow it might be Doctrine ODM or just plain files. No matter what I switch to later, only the managers layer will need to be changed — not the whole application.

Here's are some methods a typical UserManager would have:

• find($id)
• findBySomething($something)
• save(User $user)
• delete(User $user)

Also, the manager layer controls the domain logic of the system that can't be controlled on the model objects level alone. For example, UserManager, when asked to save a User, would check if the $user has a non empty $plainPassword and would encode it and set to $password. Keeping this logic in the User model class doesn't make sense because models should not depend on services and this task requires a password encoder service.

Whether or not you use repositories behind the managers layer is your choice. You could use repositories just for the retrieval methods. But I chose not to use them because they're adding a bit of additional complexity without any benefit for me. Since all the persistence stuff is hidden behind the managers layer, I can refactor it the way I want later.

Answer 2

There's no specific rules for saving entities except those related to best practices every sf2 developer should care about.

1. Putting right constructors in my entity itself? (You've to keep your entities simple and do not let them know about the persistence layer)

2. Putting it also into the Repository? (Mainly used for retrieving Entities)

3. Inserting an new entity is very related to the "form" which made it possible to enter the data, so it should be more or less in the controller? Inserting entities in not related to "form". It's ok to put it in your controller, but if you have many lines of code that create and persist your entities, You should then put a shortcut method which contains this logic. (You can also add a base controller for common methods).

4. Making a helper-class for the controller so that the work is done by the helper class and not blowing up my controller? (Take a look at the Dependency Injection Container, it allows you to create a service for this purpose).