The database maintains relationships between records using record IDs. Record IDs are only available after the record is inserted. This means that the related records, such as child object records, need to be inserted in a specific dependency order. Parent records should be inserted before child records, and the parent record IDs are used to populate the relationship (lookup) fields on the child record objects before they can be inserted.

The common pattern for this is to use the List or Map keyword to manage records inserted at a parent level, in order to provide a means to look up parent IDs, as child records are built prior to being inserted. The other reasoning for this is bulkification; minimizing the number of DML statements being used across a complex code path is vital to avoid hitting governor limits on the number of DML statements required, as such lists are favored over executing individual DML statements per record.

The focus on these two aspects of inserting data into objects can often detract from the actual business logic required, making code hard to maintain and difficult to read. The following section introduces another of Martin Fowler's patterns, the Unit Of Work, which helps address this, as well as providing an alternative to the boilerplate transaction management using SavePoint, as illustrated earlier in this chapter.

The following is Martin Fowler's definition of Unit Of Work (http://martinfowler.com/eaaCatalog/unitOfWork.html):

In an extract from the web page, he also goes on to make these further points:

Although these statements don't appear to relate to the Lightning Platform, there are parallels with respect to the cost of making multiple DML statements, both in terms of governors and general performance. There is also a statement about transaction management at a business (or service) level, which applies to the responsibility of the Service layer.

In order to best illustrate these benefits, let's review the implementation of a service to load some historic data into the Season, Race, Driver, and Contest objects. Each of these objects has several relationships, as illustrated in the following screenshot:

Consider the following sample JSON format to import data into the application:

{ 
  "drivers": [ 
  { 
    "name": "Lewis Hamilton", 
    "nationality": "British", 
    "driverId": "44", 
    "twitterHandle": "lewistwitter" 
  }], 
  "seasons": [ 
  { 
    "year": "2013", 
    "races": [ 
    { 
      "round": 1, 
      "name": "Spain", 
      "contestants": [ 
      { 
        "driverId": "44", 
        "championshipPoints": 44, 
        "dnf": false, 
        "qualification1LapTime": 123, 
        "qualification2LapTime": 124, 
        "qualification3LapTime": 125 
      }] 
    }] 
  }] 
}

The preceding JSON code is an example of a structure is used by the sample code to effectively load records into multiple objects, as shown in the earlier screenshot. Parsing this JSON and persisting it into the objects is made easier by using the Unit Of Work since the developer does not need to think about the relationship order or performing separate DMLs for each. In order to understand this benefit better, we first take a look at how this looks without the Unit Of Work.