Anemic Model vs DTO vs Active Records

Question

It's not very clear to me how a class should be designed:

• Anemic Model Domain states:

The fundamental horror of this anti-pattern is that it's so contrary to the basic idea of object-oriented designing; which is to combine data and process them together. The anemic domain model is just a procedural style design, exactly the kind of thing that object bigots like me ... have been fighting since our early days in Smalltalk. What's worse, many people think that anemic objects are real objects, and thus completely miss the point of what object-oriented design is all about. In an anemic domain design, business logic is typically implemented in separate classes which transform the state of the domain objects. Fowler calls such external classes transaction scripts. This pattern is a common approach in Java applications, possibly encouraged by technologies such as early versions of EJB's Entity Beans, as well as in .NET applications following the Three-Layered Services Application architecture where such objects fall into the category of "Business Entities" (although Business Entities can also contain behavior)

• DTO (Data Transfer Object)

The difference between data transfer objects and business objects or data access objects is that a DTO does not have any behavior except for storage and retrieval of its own data (accessors and mutators). DTOs are simple objects that should not contain any business logic that would require testing.

• Active record pattern

Refer to wikipedia

• Now refer also to this Q&A: How is called DTO class that also access db?

It seems that DTO should be only been used to share data between webservices, but, at the same time, Active Record which are aware of their persistance on DB are also bad.

So which kind of logic should be putted in the class which are cointaining the data taken from the database?

Answer 1

Let's get some concepts straight:

• Domain model: Is the model that contains the business rules. It consists of objects that represent concepts used by the business and its processes.

• DTO: as the name implies, a data transfer object is a way to pass the data from/to the domain model. There are several uses of DTOs on different layers of the application:

  • Resources: Are DTOs returned from a RESTful API.

  • DAO: Are DTOs send to and returned from a persistence layer.

  • View model: Are DTOs send to and returned from a view on the presentation layer.

So you see, DTO is a very general concept that is implemented in several ways in an application.

The Domain Model is composed of business objects (also called domain objects). It is not composed of DTOs.

These objects must enforce the rules of the business and do that by exposing methods. If you put those rules somewhere else instead, the domain object has to expose its internal data (effectively becoming a DTO), so the object that contains the logic can process it.

Experience has proved that this is harder to maintain and to change to accommodate future requirements. It also goes against the OOP tenets. This is why it is considered an antipattern and even given a name: anemic domain model.

Answer 2

You should have your own domain entities. You can use Active Record in the persistence layer. See it as a database table without any function but to save and retrieve objects from the database. Then you could have factories that create your domain entities with the data in the AR. Now you have freedom to use polymorphism, design patterns and apply oop principles to your domain entities.

The idea is not to put logic into the AR classes. Use them just because you don't want to write direct SQL queries.

An User AR is mapped to an Users table, but from that data a factory can build either a subscriber or an user. I wrote a bit about this in this blog post: http://thesolidphp.com/reducing-code-complexity-through-good-design/