Any ideas / feedback are welcome 🙂
I run into a problem in how to handle business logic around my Doctrine2 entities in a big Symfony2 application. (Sorry for the post length)
After reading many blogs, cookbook and others ressources, I find that :
- Entities might be used only for data mapping persistence ("anemic model"),
- Controllers must be the more slim possible,
- Domain models must be decoupled from persistence layer (entity do not know entity manager)
Ok, I'm totally agree with it, but :
where and how handle complex bussiness rules on domain models ?
A simple example
OUR DOMAIN MODELS :
- a Group can use Roles
- a Role can be used by different Groups
- a User can belong to many Groups with many Roles,
In a SQL persistence layer, we could modelize these relations as :
OUR SPECIFIC BUSINESS RULES :
- User can have Roles in Groups only if Roles is attached to the Group.
- If we detach a Role R1 from a Group G1, all UserRoleAffectation with the Group G1 and Role R1 must be deleted
This is a very simple example, but i'd like to kown the best way(s) to manage these business rules.
Solutions found
1- Implementation in Service Layer
Use a specific Service class as :
class GroupRoleAffectionService {
function linkRoleToGroup ($role, $group)
{
//...
}
function unlinkRoleToGroup ($role, $group)
{
//business logic to find all invalid UserRoleAffectation with these role and group
...
// BL to remove all found UserRoleAffectation OR to throw exception.
...
// detach role
$group->removeRole($role)
//save all handled entities;
$em->flush();
}
- (+) one service per class / per business rule
- (-) API entities is not representating to domain : it's possible to call
$group->removeRole($role)
out from this service. - (-) Too many service classes in a big application ?
2 – Implementation in Domain entity Managers
Encapsulate these Business Logic in specific "domain entities manager", also call Model Providers :
class GroupManager {
function create($name){...}
function remove($group) {...}
function store($group){...}
// ...
function linkRole($group, $role) {...}
function unlinkRoleToGroup ($group, $role)
{
// ... (as in previous service code)
}
function otherBusinessRule($params) {...}
}
- (+) all businness rules are centralized
- (-) API entities is not representating to domain : it's possible to call $group->removeRole($role) out from service…
- (-) Domain Managers becomes FAT managers ?
3 – Use Listeners when possible
Use symfony and/or Doctrine event listeners :
class CheckUserRoleAffectationEventSubscriber implements EventSubscriber
{
// listen when a M2M relation between Group and Role is removed
public function getSubscribedEvents()
{
return array(
'preRemove'
);
}
public function preRemove(LifecycleEventArgs $event)
{
// BL here ...
}
4 – Implement Rich Models by extending entities
Use Entities as sub/parent class of Domain Models classes, which encapsulate lot of Domain logic. But this solutions seems more confused for me.
For you, what is the best way(s) to manage this business logic, focusing on the more clean, decoupled, testable code ? Your feedback and good practices ? Have you concrete examples ?
Main Ressources :
- Symfony managing entities
- Symfony2/Doctrine, having to put business logic in my controller? And duplicating controller?
- Extending Doctrine Entity in order to add business logic
- http://iamproblematic.com/2012/03/12/putting-your-symfony2-controllers-on-a-diet-part-2/
- http://l3l0.eu/lang/en/2012/04/anemic-domain-model-problem-in-symfony2/
- https://leanpub.com/a-year-with-symfony
Best Answer
See here: Sf2 : using a service inside an entity
Maybe my answer here helps. It just addresses that: How to "decouple" model vs persistance vs controller layers.
In your specific question, I would say that there is a "trick" here... what is a "group"? It "alone"? or it when it relates to somebody?
Initially your Model classes probably could look like this:
UserManager would have methods for getting the model objects (as said in that answer, you should never do a
new
). In a controller, you could do this:Then...
User
, as you say, can have roles, that can be assigned or not.I have simplified, of course you could add by Id, add by Object, etc.
But when you think this in "natural language"... let's see...
See more in detail:
$user = $manager->getUserById( 33 );
The second is like redundant, as I got the group thru Alice. You can create a new class
GroupSpecificToUser
which inherits fromGroup
.Similar to a game... what is a game? The "game" as the "chess" in general? Or the specific "game" of "chess" that you and me started yesterday?
In this case
$user->getGroups()
would return a collection of GroupSpecificToUser objects.This second approach will allow you to encapsulate there many other things that will appear sooner or later: Is this user allowed to do something here? you can just query the group subclass:
$group->allowedToPost();
,$group->allowedToChangeName();
,$group->allowedToUploadImage();
, etc.In any case, you can avoid creating taht weird class and just ask the user about this information, like a
$user->getRolesForGroup( $groupId );
approach.Model is not persistance layer
I like to 'forget' about the peristance when designing. I usually sit with my team (or with myself, for personal projects) and spend 4 or 6 hours just thinking before writing any line of code. We write an API in a txt doc. Then iterate on it adding, removing methods, etc.
A possible "starting point" API for your example could contain queries of anything, like a triangle:
Events
As said in the pointed article, I would also throw events in the model,
For example, when removing a role from a user in a group, I could detect in a "listener" that if that was the last administrator, I can a) cancel the deletion of the role, b) allow it and leave the group without administrator, c) allow it but choose a new admin from with the users in the group, etc or whatever policy is suitable for you.
The same way, maybe a user can only belong to 50 groups (as in LinkedIn). You can then just throw a preAddUserToGroup event and any catcher could contain the ruleset of forbidding that when the user wants to join group 51.
That "rule" can clearly leave outside the User, Group and Role class and leave in a higher level class that contains the "rules" by which users can join or leave groups.
I strongly suggest to see the other answer.
Hope to help!
Xavi.