0

I've read that business logic for entities should be in a separate class (service) instead of being inside an entity class. That sounds correct for me and no problem with it, but what happens when there is entity inheritance?

I mean, I have two entities "Commute" and "SingleRide" with an abstract superclass called Ride. These two classes share some logic so a service for that would be ok, but at the same time each one has their own logic.

For instance, if I want to get a "ride description" which will be different depending on the entity class, how can I deal with this using a single service for "rides"? Should I create a service for each ride subclass? (repeating the entity structure)

In this case, how can I manage "rides" in a polymorphic way?

Izzy
  • 53
  • 3

1 Answers1

0

Add any shared logic on the abstract class. I mean, things that RIDES have in common.

All specific implementations go on the children, things they do that no one else does.

Use services to place logic not related to a specific type, that can be used in a range of different situations. (E.g: Templating, database access, logging, file access and so on are Symfony services, they are general purpose functionality that can be injected somewhere else, but does not coupled with any entity or specific functionality)

ButterDog
  • 5,115
  • 6
  • 43
  • 61
  • Thanks for your answer. I've thought that in Symfony entity classes should only manipulate data to be store in database and business logic should be outside those classes (in some helper services). – Izzy Nov 14 '12 at 10:22
  • I mean, those entity classes should also manage templating methods, like "getLongDescription"? In that case, I could not use translator service inside the entity class...I am still a bit confused. Thanks anyway! – Izzy Nov 14 '12 at 10:31
  • Well, I'm not quite sure what are you trying to do, but basically, entities are just a way to map some data between your data storage (could be a database or any other source) and your application logic. In most cases they are just simple clases with a bunch of fields, getters and setters. They may also contain some basic logic, but not your busines-logic, nor templating, nor validation (there are services -TWIG, validator- that do that). – ButterDog Nov 14 '12 at 16:30
  • What you should do is to keep just data in the entity, use the controllers to fetch the required entities and pass them to a TWIG template where you can render them with any given format (html, csv, json, xml...) and translation (use the translator component on your templates). If you want to traslate the entity data, you could create different fields like 'en_description', 'fr_description', 'es_description' on your entity and create a method like 'getDescription(Locale)', 'getLongDescription(Locale)', it really depends on your desing and what you are trying to do. – ButterDog Nov 14 '12 at 16:36