Today we end that chapter , with the Data Mapper pattern
A. The problem
Objects and relational databases have different mechanisms for structuring data. Many parts of an object, such as collections and inheritance, aren’t present in relational databases. When you build an object model with a lot of business logic it’s valuable to use these mechanisms to better organize the data and the behavior that goes with it. Doing so leads to variant schemas; that is, the object schema and the relational schema don’t match up. You still need to transfer data between the two schemas, and this data transfer becomes a complexity in its own right. If the in-memory objects know about the relational database structure, changes in one tend to ripple to the other.
How to make the object schema and the relational schema work together in a cohesive way ?
B. The Solution
The Data Mapper is a layer of software that separates the in-memory objects from the database. Its responsibility is to transfer data between the two and also to isolate them from each other. With Data Mapper the in-memory objects needn’t know even that there’s a database present; they need no SQL interface code, and certainly no knowledge of the database schema.
C. How it works ?
The way it works, we have to deal with two important steps :
1 - Finder : The step of finding is an important step, it goes from the presentation layer to the domain layer, and the domain object after going from object to objects , makes the request to the mapper layer.
2 - Mapping Data to Domain Fields : Once the mapper has retrieved the response from the database , we have to find a way to map the column from the database to the domain fields. The first solution is to have Rich Constructor it’s nice to have a well-formed object from the start. This also means that, if you have an immutable field, you can enforce it by not providing any method to change its value. The second is to use a no args constructor the point here is to create an empty object and then populate it with the mandatory data.
Here we have a figure to show the sequential order :
D. When to use it ?
To say it simply :
The primary occasion for using Data Mapper is when you want the database schema and the object model to evolve independently. The most common case for this is with a Domain Model. Data Mapper’s primary benefit is that when working on the domain model you can ignore the database, both in design and in the build and testing process. The domain objects have no idea what the database structure is, because all the correspondence is done by the mappers.
And how can i test that :
So the test for using these patterns is the complexity of the business logic. More complicated logic leads you to Domain Model and therefore to Data Mapper.
Conclusion: Here we do not have the coupling between the domain and the datasource, the data mapper for me is a good layer for low coupling
Top comments (0)