>Data Mapper is the software layer that separates the in-memory objects from the database.
>Its responsibility is to transfer data between the objects and database and isolate them from each other.
>If we obtain a Data Mapper, it is not necessary for the in-memory object to know if the database exists or not.
>The user could directly manipulate the objects via Java command without having knowledge of SQL or database.
The Data Mapper pattern aims to create an abstraction layer between the database and the business logic, allowing them to evolve independently. It maps data from the database objects to in-memory data structures and vice versa, minimizing direct dependencies between the application's core logic and the underlying database structure.
## Explanation
Real world example
>When a user accesses a specific web page through a browser, he only needs to do several operations to the browser.
> The browser and the server will take the responsibility of saving data separately.
> You don't need to know the existence of the server or how to operate the server.
> When a user accesses a specific web page through a browser, he only needs to do several operations to the browser. The browser and the server will take the responsibility of saving data separately. You don't need to know the existence of the server or how to operate the server.
In plain words
>A layer of mappers that moves data between objects and a database while keeping them independent of each other.
> A layer of mappers that moves data between objects and a database while keeping them independent of each other.
Wikipedia says
>A Data Mapper is a Data Access Layer that performs bidirectional transfer of data between a persistent data store
> (often a relational database) and an in-memory data representation (the domain layer). The goal of the pattern is to
> keep the in-memory representation and the persistent data store independent of each other and the data mapper itself.
> This is useful when one needs to model and enforce strict business processes on the data in the domain layer that do
> not map neatly to the persistent data store.
> A Data Mapper is a Data Access Layer that performs bidirectional transfer of data between a persistent data store (often a relational database) and an in-memory data representation (the domain layer). The goal of the pattern is to keep the in-memory representation and the persistent data store independent of each other and the data mapper itself. This is useful when one needs to model and enforce strict business processes on the data in the domain layer that do not map neatly to the persistent data store.
**Programmatic Example**
>We have the student class to defining Students' attributes includes studentId, name and grade.
>We have an interface of StudentDataMapper to lists out the possible behaviour for all possible student mappers.
>And StudentDataMapperImpl class for the implementation of actions on Students Data.
The Data Mapper is a design pattern 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. This pattern promotes the [Single Responsibility Principle](https://java-design-patterns.com/principles/#single-responsibility-principle) and [Separation of Concerns](https://java-design-patterns.com/principles/#separation-of-concerns).
In the data-mapper module, the pattern is demonstrated using a Student class and a StudentDataMapper interface.
The Student class is a simple POJO (Plain Old Java Object) that represents a student. It has properties like studentId, name, and grade.
thrownewDataMapperException("Student ["+name+"] is not found");
}
}
publicList<Student>getStudents(){
returnthis.students;
}
}
// ...
}
```
>The below example demonstrates basic CRUD operations: Create, Read, Update, and Delete between the in-memory objects
> and the database.
The StudentDataMapper interface defines the operations that can be performed on Student objects. These operations include insert, update, delete, and find.
The App class contains the main method that demonstrates the use of the StudentDataMapper. It creates a Student object, inserts it into the database, finds it, updates it, and finally deletes it.
mapper.update(student);
LOGGER.debug(STUDENT_STRING+student+", is updated");
LOGGER.debug(STUDENT_STRING+student+", is going to be deleted");
13:54:29.238 [main] DEBUG com.iluwatar.datamapper.App -- App.main(), student : Student(studentId=1, name=AdamUpdated, grade=A), is going to be deleted
```
## Class diagram

## Applicability
Use the Data Mapper in any of the following situations
*when you want to decouple data objects from DB access layer
*when you want to write multiple data retrieval/persistence implementations
*When there's a need to decouple the in-memory objects from the database entities to promote the [Single Responsibility Principle](https://java-design-patterns.com/principles/#single-responsibility-principle) and [Separation of Concerns](https://java-design-patterns.com/principles/#separation-of-concerns).
*In applications requiring an ORM tool to bridge the gap between object-oriented models and relational databases.
* When working with complex database schemas where direct data manipulation and object creation lead to cumbersome and error-prone code.
## Tutorials
@@ -186,16 +135,36 @@ Use the Data Mapper in any of the following situations
* [Data Transfer Object Pattern in Java - Implementation and Mapping (Tutorial for Model Mapper & MapStruct)](https://stackabuse.com/data-transfer-object-pattern-in-java-implementation-and-mapping/)
## Known uses
* ORM frameworks such as Hibernate in Java.
* Data access layers in enterprise applications where business logic and database management are kept separate.
* Applications requiring database interactions without tying the code to a specific database implementation.
> Data model follows the single function principle
Benefits:
* Promotes [Single Responsibility Principle](https://java-design-patterns.com/principles/#single-responsibility-principle) by separating persistence logic from business logic.
* Enhances maintainability and readability by centralizing data interaction logic.
* Improves application's ability to adapt to changes in the database schema with minimal changes to the business logic.
Trade-offs:
* Introduces complexity through the additional abstraction layer.
* Might lead to performance overhead due to the abstraction layer, especially in large-scale applications or with complex queries.
* Requires developers to learn and understand the abstraction layer in addition to the database and ORM framework being used.
## Related patterns
* [Active Record Pattern](https://en.wikipedia.org/wiki/Active_record_pattern)
*Active Record: Combines data access logic and business logic in the domain entities themselves, contrary to Data Mapper's separation of concerns.
* Object–Relational Mapping (ORM): A technique to map object-oriented programming language data to a relational database.
* [Repository](https://java-design-patterns.com/patterns/repository/): Provides an abstraction of the data layer, acting as a collection of domain objects in memory.
* [Unit of Work](https://java-design-patterns.com/patterns/unit-of-work/): Manages transactions and keeps track of the objects affected by a business transaction to ensure changes are consistent and transactional.
## Credits
* Patterns of Enterprise Application Architecture
* [Java Persistence with Hibernate](https://amzn.to/3VNzlKe)
* [Clean Architecture: A Craftsman's Guide to Software Structure and Design](https://amzn.to/3xyEFag)
* @throws Exception if any execution error during test
*/
@Test
voidtestEquality()throwsException{
voidtestEquality(){
/* Create some students */
finalvarfirstStudent=newStudent(1,"Adam",'A');
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.