Symfony2 MVC: where does my code belong?

Question

I'm seeking clarification on whether to put code in a controller, an entity or to make a service.

I have 'cardset' and 'card' objects (where many of the latter are embedded in the former, MongoDB), represented by normal PHP classes/objects. These contain attributes e.g. 'id', 'postal_address'.

I have a method that generates a PDF of a card. Currently I have that inside the 'Card' object so from a Controller I can call:

$card->makePDF()

That seems clean and OO to me, but I suspect I'm wrong.

If I put all the logic in the controller that gets long and unwieldy, and I'm not sure the controller is the place for methods that act on my objects. Is that what services are for?

To try and summarise: should an object know all the regular things it could do 'to itself' and have them inside as member functions, or should methods elsewhere be passed the object to act upon. If so, where should those methods be kept?

I'm pretty sure it's not a 'Repository' because that just seems to help retrieve/store entities.

Thanks!

Answer 1

Short answer:

PDF generation should be a service, not a method on an object.

Longer answer:

In general, and in Symfony2 especially, models should just be used to store data. Controllers are used to manipulate relationships between models, and Views are used to express the data in human- or computer-readable form. Services are for things that don't really fit into any of the above -- things that don't have to do with your web application's state.

A good example is sending emails. Emails contain data (model). Users have sent Emails (controller). Emails look a certain way (view). However, the act of actually sending emails is independent of the web application's state (all the service knows is it was asked to send this email to these people). Thus, it makes sense that there is an independent service that just handles sending emails.

Similarly, the act of generating PDF files is independent of the state of the web application. A PDF generator doesn't need to know about what's going on in your app, it just knows it was asked to make a PDF.

Answer 2

If you will follow SOLID principles you will get to the SRP which states that your class should have one single responsibility.

I think it is obvious that generating one pdf is something diferent than modeling data and mapping your database( your entity does that)

Answer 3

• Symfony2 is NOT an MVC structure (as said by Fabien himself) precisely because it gives all the V (twig) and C (controllers) but does NOT give the M part. The M part is "free" to be built as you want.

• There is a major confussion, people "think" that Doctrine IS the model. But that's not true. What we do is TWO directories in the Bundle, one called "Document" for the Doctrine-ODM classes and one called "Model" where the "business logic" reside.

Personally I see that $card->makePDF() makes sense...

But $card should be a "model card", which inherits or has an underlying object "data card" which is the doctrine class.

You can play with inheritance, or with interfaces, with creators or whatever you want to relate "model-card" to "data-card" but the key is that "doctrine is not BUSINESS model" it is simply a persistance layer and your model are "plain classes" that you can build to wrap your data inside and make the controllers to consume the model, not the data.