Object Mapping and Entities
Indeed, currently, almost always applications need a persistence layer or service to store any information in long-term, moreover, all kind of interaction with this data storage technology, most trivially the CRUD actions. Usually, an application has an entity, an object fundamentally defined not by its attributes, but by its identity, it works with object-oriented, conversely, the data structure in the database. A mapper object to the structure is required, thus to make more accessible this process to a developer there are both ORM, Object-relational mapping, and OxM, object to wherever NoSQL technology mapper, to avoid boilerplate in the application code. In contrast, this facility has complained to the data architecture. So what is wrong with ORM and OxM? This post will cover more about this.
DAO layer
Regardless of the programming language, to facilitate the understanding and maintenance of the code, the projects are divided by components and there are some very important patterns such as MVC that has three layers. For the communication between the application and the database, there is a sublayer that is the DAO or the Repository, which in both cases work with the objective to abstract the information from the database. For a concept like DDD, the concept of Repository is quite simple: mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects. That is, to abstract enough that the business is not aware of the technology chosen to persist the information.
Is ORM the problem?
This ease of abstraction made the developer’s life much easier, but it had great consequences. The fact is that using ORM or OxM has become synonymous with not worrying about what’s in the persistence layer. There were several impacts on the performance, thus initiating the true civil war between the developer and the data architect. Several acclaiming articles that the ORM is an anti-pattern. On the one hand, the ease of developing with the mapper and on the other the impact on the performance, but is ORM the problem?
The fact is that this transfer will have to be done by someone, with or without boilerplate. However, it is very important to understand the mistake impedance of the mapper, which are the technical debts found when performing the mapper. This impedance is diverse:
Encapsulate: in data structures encapsulation is a major challenge, after all, the database is just a data structure and not the object. Using the Clean Code as a reference, it is worth remembering that the main difference between an object and a structure is that the first one hides the data to expose a behavior.
Object Oriented in Databases?
Inheritance and Polymorphism: Concepts like interface, polymorphism among other structures are not supported. The closest databases have to inheritance is, for example, Postgresql that allows one table to extend from another, so the fields will be part of the inherited table.
Different Data and Types: To avoid duplicating logic and leaving code consistently there is a strategy of creating types or Vos. These types of classes contain small but precious, logic in which, for example, the money rule in which both the value and the currency coincide, will prevent, for example, making sums when the currencies are different. These types are most welcome in object orientation, however, they are not always supported by given databases.
If we take the Clean Architecture book as a reference, a good first step is to separate what matters or not from your project, that is, and we will assume that what matters is the business rule, that is, any other technology should be separated and this includes persistence technology.
Having defined a class or structure that will be stored from that which will be the entity of a rich model has some advantages:
It gets the business transparent of technology and any change will not impact the business rule at all. Hiding the client as you are persisting in the database, this will allow database modeling to be optimized without worrying and impacting on the rich business model. In addition to changing the database type transparently as well. The possibility of hiding sensitive data: As mentioned earlier, this approach allows an infrastructure information to simply not go into the model since this refers to the database, for example, versioning or auditing information of the data.
