When using an ORM to represent a table, is it wise to have non-table specific functions?

Question

For example (not verbatim)

/**
@Entity
*/
class Event
{
   /**
      @Column 
   */
   protected $time_start;
   /** .. */
   protected $time_end;

   /** getters, setters, etc */

   /** @return duration of event as a string, non-table function */
   public function getDuration() { ... }
}

Or should the ORM just be the table, and nothing more?

This could be a subjective view, as everyone has their own opinions, but in programming there and things you do and things you really shouldn't do. I was just wondering if this is one of those cases.

Answer 1

Not, it is not a good idea. If nothing else, would be violating Single responsibility principle .

If you are making an ORM, your instances should deal only with data storage/retrieval. In your example getDuration() is part of domain business logic and should reside within domain objects .

Basically, what you are dealing here is the difference between data mapper and active record patterns. And, if you are trying to write code that adheres to SOLID principles, one would consider active record to be an antipatter, which in long term causes unmitigated technical debt .

Answer 2

Except if there is some application-specific reasons for not having the function, the answer is a big YES. Let me explain why:

1. In OOP, an object is not just a data structure. It ties state and behavior together. This is a basic principle of OOP. It has a state, and it has methods that modify the state. What is and Entity? It is an object, a business object. Business objects contain business data and logic. As such, they do need to have methods that perform business logic. Removing business logic from business objects is against the essence of OOP. Because, ultimately you will need to implement that logic somewhere, but that will not be the right place. That code will somehow need to access the state of the business object, and that will, in most cases break the principle of Information hiding (Encapsulation) which is one of the reasons why we have OOP in the first place.

2. Now, with regard to ORM! Here you have two needs to fulfill, an object-oriented design and ORM. Now ask which one has the precedence over the other, or, which one comes first. Do you first consider ORM (or any other means for storage) first and then design your classes? Or do you design you classes and then have them mapped/stored? The first method is the right way. You design your application and then let ORM follow from this design.

3. Will non-accessor methods prevent you from having ORM. NO. These methods will not prevent you from having ORM on the object. The designers of ORM frameworks knew about the principle when they designed it.