One of the Martin Fowler's core Enterprise Application patterns is a Data Mapper. Grounded in the fundamental Seperation of Concerns (SoC) principles, this patterns seeks to hide the complexity involved data retrieval and storing.
Today's modern Java EE applications leverage the JSR-317 - Java Persistence specification to interact with the relational data stores such as Oracle, MySQL and Postgres. However, with the broad adoption of NoSQL, its now a good time to look at how this pattern can apply when interacting with these data stores.
NoSQL Data Stores
The fast adoption of MongoDB has largely been driven by its developer-centric approach and its ability to make app development faster. How does it do this? Well, its driven by many reasons, but especially the following:
Data is stored in a structure that resembles how it is consumed, so no more square pegs / round hole problems. Data to be stored doesn't have to be "massaged" to fit into the datastore, and there is no "impedance mismatch" headaches.
Focus on the business object, not the supporting infrastructure. Some times type safety is just a pain, and adding in logic to continue to translate objects between application type and data store type is noise that doesn't need to be in the code.
The infrastructure should be responsible for the scaling of the data store. The application should only have to focus on business logic.
Object Document Mappers and MongoDB
However, now that we have chosen a NoSQL implementation to use, how are we going to store, modify, and retrieve our data object within our applications?
Maintaining Data Integrity
There are still some structures and relationships that MongoDB does not maintain that we will need to implement in order to maintain the cohesiveness and integrity of our data.Unit of Work
MongoDB doesn't provide transactions, so we can use this technique to maintain our changes and save them in a one action.Identity Map
Documents in MongoDB can get pretty big, fairly quickly. We want to make sure that we manage our JVM memory efficiently and ensure that each document is loaded only once. We want to use a map to help us find that object when we need to refer to it.Foreign Key Mapping
MongoDB is non-relational but we still need a way to represent relationships between objects in our domain model.
Abstraction and Encapsulation
To hide some of the ugliness associated with addressing data integrity, we're going to look at implementing an Object Document Mapping framework. And when it comes to Object Document Mapping frameworks, there are two choices - roll-your-own or code reuse.
The right choice depends on your application and how much code your team decides to maintain and as with anything, there are pros and cons to consider.
Getting Our Hands Dirty
Over the next series of articles, we are going to take a look at these different frameworks and highlight some of the lessons learned with implementing each framework and some important considerations for future projects. However, before we begin, let's establish some foundational elements.A Domain Model
To evaluate these different frameworks and techniques, we are going to use an example of a Sales Quote tracking tool. The domain model for this exercise will be as follows:
The concept is that potential customers submit requests for product pricing. A quote is generated that lists each desired product, its list price, a discount for each item, and the final price.Prerequisities
In our next article, we're going to look at Morphia. We'll use our domain model to gain an understanding of how this framework is used and discover some of its strengths and weaknesses.