ORM’s patterns

ORM is an essential tool used in most software because it’s helping software engineers to focus on building the business logic and avoid the hustle of writing simple queries (e.g insertion, deletion, etc…)

In this post, I aim to explain what an ORM does, as well as the pros and cons of using them in your projects.

Let’s get to it!

What is ORM?

ORM stands for Object-Relational Mapping. It is a technique used in software development to map the objects in an application to relational database tables. The main idea behind ORM is to abstract away the underlying database and provide a higher-level, object-oriented interface for database access and manipulation. This makes it easier to develop and maintain applications that use a database since the database access code can be generated automatically and the application code can be written in a more intuitive and expressive object-oriented style.

Some popular ORM frameworks include Hibernate (Java), Django ORM (Python), Elequint Orm (PHP ), and Entity Framework (C#).

How do ORMs work?

ORM works by creating a mapping between the objects in an application and the database tables that store the data for those objects. The ORM framework is responsible for converting the data stored in the database into objects in the application, and vice versa.

When an application needs to retrieve data from the database, it asks the ORM framework to perform the database query and return the results as objects. The ORM framework takes care of constructing the SQL query to retrieve the data, executing the query, and converting the results into objects that can be used by the application.

When an application needs to save data to the database, it passes the objects to the ORM framework, which takes care of converting the objects into the appropriate data format for storage in the database and constructing the SQL query to perform the insert or update.

The mapping between objects and database tables is typically defined using metadata, which can be specified in code, in configuration files, or using annotations. The ORM framework uses the metadata to know how to translate the objects and their properties into database tables and columns.

ORM patterns

Martin Fowler’s book “Patterns of Enterprise Application Architecture” provides a comprehensive explanation of the Object-Relational Mapping (ORM) pattern. According to Fowler, ORM is a way to map objects in an object-oriented programming language to relational database tables.

Several different patterns can be used to implement Object-Relational Mapping (ORM) as described in the book (not all of them of course!):

• Active Record: The Active Record pattern is a simple and easy-to-use ORM pattern where each database record is represented by a corresponding object in the application.
• Data Mapper: The Data Mapper pattern separates the application’s data model from the database, and provides a way to map the data stored in the database to objects in the application and vice versa.
• Table Data Gateway: The Table Data Gateway pattern is a simple and efficient ORM pattern that maps a single database table to a corresponding class in the application.
• Unit of Work: The Unit of Work pattern keeps track of all the changes that have been made to the objects in the application, and ensures that the database is updated accordingly when the transaction is committed.

Data Mapper

The Data Mapper pattern is a specific implementation of the Object-Relational Mapping (ORM) pattern that separates the application’s data model from the database. It provides a way to map the data stored in the database to objects in the application and vice versa.

In the Data Mapper pattern, data mapper classes are responsible for managing the persistence and retrieval of objects to and from the database. Each data mapper class is responsible for mapping a specific type of object, and it knows how to convert the data stored in the database into objects and vice versa.

For example, if you have a “User” class in your application, you would have a “UserMapper” class that would be responsible for loading and saving User objects from and to the database. The UserMapper class would have methods such as “findById” and “save” that would handle the retrieval and persistence of User objects, respectively.

The Data Mapper pattern provides a clear separation between the application’s data model and the database, making it easier to change the database schema or switch to a different database technology without affecting the application code.

Advantages of the Data Mapper pattern

• It can reduce the coupling between the application code and the database. The application code does not need to know the details of the database schema, and the database does not need to know the details of the application’s data model.
• The data mapper classes can provide a higher-level, object-oriented API for database access and manipulation, making it easier to write the application code. The application code can work with objects, instead of with the database directly, which can make the code more readable and maintainable.

Disadvantages of the Data Mapper pattern

• Increased complexity: Data mapper adds an extra layer of abstraction, which can make the overall architecture more complex and harder to understand.
• Performance overhead: The data mapper must translate between the domain and the persistence layer, adding a performance overhead.
• Lack of control: Data mapper can limit the ability of the developer to control the exact details of the data retrieval and storage process, as it abstracts these operations.

Active Record

The Active Record pattern is a type of Object-Relational Mapping (ORM) pattern that maps a database record to a corresponding object in the application. In this pattern, each database record is represented by an instance of an Active Record class, and the class provides methods for performing database operations such as insertion, retrieval, update, and deletion.

The main idea behind the Active Record pattern is to encapsulate the database record within the object so that the object has direct access to the data stored in the database. This allows the object to manage its persistence and retrieval and eliminates the need for a separate data access layer.

The Active Record class typically has properties that correspond to the columns of the database table, and the class provides methods for performing database operations. For example, the class might have a “save” method that inserts or updates the database record, a “find” method that retrieves a record from the database and a “delete” method that removes the record from the database.

Advantages of the Active Record pattern

• It provides a simple and intuitive way to access and manipulate data, making it easy to write the application code. The code can work directly with objects, rather than with the database, which can make the code more readable and maintainable.
• It can reduce the coupling between the application code and the database, as the database schema and structure can be changed without affecting the application code.

Disadvantages of the Active Record pattern

• Blurred responsibilities: The Active Record pattern can blur the distinction between the domain model and the persistence layer, making it harder to understand the responsibilities of each component.
• Lack of separation of concerns: The Active Record pattern can violate the principle of separation of concerns by mixing business logic with persistence logic.
• Lack of flexibility: The Active Record pattern can limit the flexibility of the system by assuming a specific database structure and persistence mechanism.

Unit of Work

The Unit of Work pattern is a type of Object-Relational Mapping (ORM) pattern that keeps track of changes made to the objects in an application and ensures that the corresponding changes are made to the database when the transaction is committed. In this pattern, the Unit of Work class acts as a central repository for changes made to the objects and is responsible for committing the changes to the database when the transaction is complete.

The main idea behind the Unit of Work pattern is to provide a way to manage the persistence of objects and ensure that the database is updated consistently and efficiently. The Unit of Work class keeps track of all the changes made to the objects, and at the end of the transaction, it sends the changes to the database in a single batch. This reduces the number of database round trips and increases the efficiency of the application.

The Unit of Work pattern is often used in combination with other ORM patterns, such as the Data Mapper pattern. In this case, the Data Mapper classes are responsible for mapping the objects to the database and vice versa, while the Unit of Work class is responsible for managing the persistence of the objects.

Advantages of the Unit of Work pattern

• It provides a centralized mechanism for managing changes to the objects and the database, making it easier to maintain the consistency and integrity of the data. It also reduces the number of database round trips, which can improve the performance of the application.
• It allows changes to be grouped into a single transaction, making it possible to roll back changes if something goes wrong. This helps to ensure the integrity of the data and prevent inconsistencies or corruption.

Disadvantages of the Unit of Work pattern

• Performance overhead: The Unit of Work pattern can add a performance overhead as it must track changes to the domain objects and persist them in a batch.
• Difficult error handling: Error handling can be difficult in a Unit of Work pattern, as any error during the commit phase can cause all changes to be rolled back.

Table Data Gateway

The Table Data Gateway pattern is a type of Object-Relational Mapping (ORM) pattern that provides a simple and efficient way to access the data stored in a database table. In this pattern, a Table Data Gateway class is used to perform the database operations, such as insertion, retrieval, update, and deletion, for a specific table.

The main idea behind the Table Data Gateway pattern is to provide a simple and efficient way to access the data stored in the database. The Table Data Gateway class provides a clear and concise API for performing database operations, and it separates the data access code from the business logic of the application.

The Table Data Gateway class typically has methods that correspond to the operations that can be performed on the database table, such as find, insert, update, and delete. The methods use SQL statements or stored procedures to interact with the database and perform the requested operation.

Advantages of the Table Data Gateway pattern

• It provides a simple way to access the data stored in the database, making it easier to write the application code. The code can work directly with the Table Data Gateway class, rather than with the database, which can make the code more readable and maintainable.
• It can reduce the coupling between the application code and the database, as the database schema and structure can be changed without affecting the application code.

Disadvantages of the Table Data Gateway pattern

• Limited functionality: The Table Data Gateway pattern only provides basic data retrieval and storage functionality and does not support advanced features such as transactions or caching.
• Lack of abstraction: The Table Data Gateway pattern provides a little abstraction over the underlying database, making it harder to change the database technology without affecting the domain model.
• Lack of scalability: The Table Data Gateway pattern can become a bottleneck as the size of the data grows, as it does not provide any advanced features for scaling or optimizing data access.

Conclusion

ORMs have a lot of topics and patterns and it’s very important to improve your knowledge about building enterprise applications, you could explore them through :

• The“ Patterns of Enterprise Application Architecture” provides a detailed explanation of the various components and techniques involved in implementing ORM.
• documentation for different ORMs likes (hibernate, entity framework, etc …)