This course is archived!
Symfony2: Organizing your Business Logic into Models
Symfony2: Organizing your Business Logic into Models¶
From Audrius
As Symfony is Request/Response rather than MVC framework what is best (business/developer ratio) structure to implement model layer into Symfony applications.
Lets say you have a lot of business logic inside your application, or porting normal MVC application to Symfony, what is best way (in your opinion) to organize structure for applications? All business logic goes into services? Fat controllers? Any other solutions?
Answer¶
As Audrius correctly points out, Symfony2 isn’t actually an MVC framework, nor does it want to be. Symfony2 is all about converting a “request” into a “response”. Behind the scenes it uses a simple routing -> controller setup. Using templates, or creating a rich service-oriented-architecture is totally optional and up to you. You can even create your own classic view layer if you want to.
This means that you have a lot of flexibility on how to organize things. But in my opinion, the answer is simple: create a service-oriented architecture where all your business logic lives in services. This means having “skinny” controllers and a “fat” model. There will of course be edge-cases, but this is almost always the best way to organize things.
Tip
If any of this “skinny controllers” and “fat” models is new to you, check out our free Dependency Injection screencast.
But this isn’t a hard rule. Having a perfectly-organized service layer is something to strive towards, but not something that’s always easy - or even good - in the real world. If you’re trying to quickly prototype something, for example, then creating services is probably not as good as putting the logic directly in your controller. In fact, you might even argue that logic should live in the controller unless you’re going to unit test it or until you need to re-use it.
In other words, the goal is to put your logic in services. Balance that with the real-world requirements of getting things done quickly to compromise between developing quickly and having clean maintainable code. Adding a lot of logic to your controller is a perfect example of Technical Debt, which is a natural part of the development process.
Cheers!
OTOH Storing your business logic in services isn't really the best approach. Business logic is supposed to live in models. Symfony documentation very nicely states what services are for and altough some deviation from their definition is neccessary it's not recommended.