We will continue to talk about our chapter 3 about Mapping to relational databases but with differents points.
So let's go 😁
1️⃣ The Behavioural Problem
That behavioral problem is how to get the various objects to load and save themselves to the database. At first sight this doesn’t seem to be much of a problem. A customer object can have load and save methods that do this task. Indeed, with Active Record this is an obvious route to take. As you read objects and modify them, you have to ensure that the database state you’re working with stays consistent.
- Solution Pattern: Unit of Work
A pattern that’s essential to solving both of these problems is Unit of Work. A Unit of Work (184) keeps track of all objects read from the database, together with all objects modified in any way. It also handles how updates are made to the database. Instead of the application programmer invoking explicit
save methods, the programmer tells the unit of work to commit. That unit of work then sequences all of the appropriate behavior to the database, putting all of the complex commit processing in one place. Unit of Work (184) is an essential pattern whenever the behavioral interactions with the database become awkward. A good way of thinking about Unit of Work (184) is as an object that acts as the controller of the database mapping. Without a Unit of Work (184), typically the domain layer acts as the controller; deciding when to read and write to the database.
- 🏁 Good to Know
If you’re using a Domain Model , you’ll usually arrange things so that linked objects are loaded together in such a way that a read for an order object loads its associated customer object. However, with many objects connected together any read of any object can pull an enormous object graph out of the database. To avoid such inefficiencies you need to reduce what you bring back yet still keep the door open to pull back more data if you need it later on. Lazy Load relies on having a placeholder for a reference to an object.
2️⃣ Structural Mapping Patterns
The central issue here is the different way in which objects and relations handle links, which leads to two problems. First there’s a difference in representation. Objects handle links by storing references that are held by the runtime of either memory-managed environments or memory addresses. Relational databases handle links by forming a key into another table. Second, objects can easily use collections to handle multiple references from a single field, while normalization forces all relation links to be single valued. This leads to reversals of the data structure between objects and tables.
- ✅ Foreign Key Mapping
Each time you
come across a foreign key in the table, you use Foreign Key Mapping (236) (see Figure 3.5) to wire up the appropriate inter-object reference. If you don’t have the key in the Identity Map (195), you need to either go to the database to get it or use a Lazy Load (200). Each time you save an object, you save it
into the row with the right key. Any inter-object reference is replaced with the target object’s ID field.
Next time we will talk about another subject 😃
Top comments (0)