ktsdesign - Fotolia
What is the best pattern to use for data persistence?
When designing an application, developers must decide how to implement data persistence. Brad Irby explains which data persistence pattern to consider.
When designing an application you must decide how to implement the data persistence. Two main patterns are available: Data Mapper pattern or the Active Record pattern. With the Active Record pattern, logic for interacting with the database (retrieving, updating and deleting) is included in the data object. This allows such syntax as MyObject.Save(). The Data Mapper pattern introduces a separate class that implements the database interaction, leaving the data object to just hold the data (more like a Data Transfer Object). This produces syntax such as MyMapper.Save(MyObject).
Both patterns have their strengths and weaknesses. In this tip, I discuss the pros and cons of each pattern and examine the important considerations to take before settling on one.
Persistence targets
Active Record pattern is attractive when there is a single target for object persistence that is known in advance. You can code all your persistence logic into the object where it is convenient to update when necessary. The Data Mapper pattern is useful when your code must support multiple persistence targets, such as Oracle, Microsoft SQL Server, MySQL, APIs, streaming data feeds and so on. The only thing you need to change to support an additional persistence source is to write an additional mapper.
Where the Data Mapper really stands out is when it's possible to have multiple persistence locations. Assume that you want to persist objects to a database as well as via a Web service each time a save is requested. Such a setup is trivial with Data Mapper, but could be quite difficult with Active Record. Likewise when one logic is persisted partially in one location and in another.
Flexibility in writing persistence code
Active Record is more flexible than Data Mapper when persisting data because it is easier to manipulate objects in the store -- if your code has an object it can persist that object easily because the persistence logic travels with the object. With Data Mapper, on the other hand, you must have access to the appropriate Mapper object in order to save. If you like to have all persistence logic in a single place, Data Mapper would be a better way to go.
Business rule implementation
In the Active Record, business rules are enforced in the data object. In Data Mapper, the rules are enforced in the mapper. This becomes important when considering the types of business rules you must implement. If your rules are complicated and interconnected they are more easily implemented via Data Mapper, whereas if business rules typically involve only the object itself Active Record is more appropriate.
Consider a sales tracking system where each customer has a credit limit they are not allowed to exceed, but a company also has a limit to the credit it can provide to all customers combined. Each time a potential sale is created, the code must check the outstanding credit of the purchaser as well as the selling company. If you are using Active Record, the customer object must be able to check the outstanding credit of the company during a save, which is not a very wise design decision. With Data Mapper, that logic would be implemented in the save method.
Here is a convenient rule of thumb: If the business rules only concern an object itself, or any objects that it owns, Active Record is a good choice. If business rule logic needs to encompass objects that have no relationship to each other, consider Data Mapper.
Complication urges data mapper
Although each application must be judged on its own merits, when faced with complicated business logic I prefer to use Data Mapper. This pattern provides a central place to edit the business rule logic, and also lends itself well to unit testing that logic.
If the application has fairly simple business rules I prefer Active Record. Imagine a Web or mobile application targeted at consumers that is primarily concerned with storing and retrieving simple relationships for each user.
