Data Mapper Pattern: Mastering Data Persistence in Swift

5.9 Data Mapper Pattern

In the world of software development, maintaining a clean separation between business logic and data persistence logic is crucial for creating maintainable and scalable applications. The Data Mapper Pattern is a structural design pattern that facilitates this separation by abstracting the data access logic from the business logic. This pattern is particularly useful in applications where complex data transformations are required or where the data source is likely to change.

Intent

The primary intent of the Data Mapper Pattern is to separate business logic from data persistence logic. This separation ensures that domain objects remain unaware of how data is stored or retrieved, promoting a clean architecture and making the system easier to maintain and extend.

Key Participants

• Domain Model: Represents the core business logic and data structure of the application. It remains agnostic of the data persistence mechanism.
• Data Mapper: Acts as a bridge between the domain model and the data source. It handles the conversion of domain objects to data source representations and vice versa.
• Data Source: The underlying storage mechanism, such as a database or a file system.

Applicability

Use the Data Mapper Pattern when:

• You need to maintain a strict separation between business logic and data access logic.
• Your application requires complex data transformations that are not easily handled by Active Record patterns.
• You anticipate changes in the data source or persistence mechanism.
• You want to test business logic independently of data access code.

Implementing Data Mapper in Swift

Let’s delve into how we can implement the Data Mapper Pattern in Swift. We’ll create a simple example involving a User domain model and a hypothetical database.

Step 1: Define the Domain Model

First, define the User domain model. This model should be free of any persistence logic.

1struct User {
2    let id: Int
3    var name: String
4    var email: String
5}

Step 2: Create the Data Mapper Interface

Next, create a protocol that defines the responsibilities of the data mapper. This protocol will include methods for converting between domain models and data source representations.

1protocol UserMapper {
2    func find(byId id: Int) -> User?
3    func save(_ user: User)
4    func delete(_ user: User)
5}

Step 3: Implement the Data Mapper

Implement the data mapper by creating a class that conforms to the UserMapper protocol. This class will interact with the database to perform CRUD operations.

 1class DatabaseUserMapper: UserMapper {
 2    private var database: [Int: [String: Any]] = [:] // Simulating a database with a dictionary
 3
 4    func find(byId id: Int) -> User? {
 5        guard let data = database[id],
 6              let name = data["name"] as? String,
 7              let email = data["email"] as? String else {
 8            return nil
 9        }
10        return User(id: id, name: name, email: email)
11    }
12
13    func save(_ user: User) {
14        database[user.id] = ["name": user.name, "email": user.email]
15    }
16
17    func delete(_ user: User) {
18        database.removeValue(forKey: user.id)
19    }
20}

Swift Unique Features

Swift offers several unique features that can enhance the implementation of the Data Mapper Pattern:

• Protocol-Oriented Programming (POP): Use protocols to define the data mapper interface, promoting flexibility and testability.
• Extensions: Extend existing types to add data mapping capabilities without modifying the original type.
• Generics: Implement generic data mappers that can handle multiple domain models.

Differences and Similarities

The Data Mapper Pattern is often compared to the Active Record Pattern. While both patterns deal with data persistence, they have distinct differences:

• Data Mapper: Separates domain logic from data access logic. Domain objects are unaware of the database.
• Active Record: Combines domain logic and data access logic within the same object. Domain objects are responsible for their persistence.

Visualizing the Data Mapper Pattern

To better understand the Data Mapper Pattern, let’s visualize the relationship between the domain model, data mapper, and data source.

    classDiagram
	    class User {
	        +Int id
	        +String name
	        +String email
	    }
	
	    class UserMapper {
	        <<interface>>
	        +find(byId: Int) User?
	        +save(user: User)
	        +delete(user: User)
	    }
	
	    class DatabaseUserMapper {
	        +find(byId: Int) User?
	        +save(user: User)
	        +delete(user: User)
	    }
	
	    class Database {
	        +[Int: [String: Any]] data
	    }
	
	    UserMapper <|.. DatabaseUserMapper
	    DatabaseUserMapper --> Database : interacts with
	    DatabaseUserMapper --> User : maps to/from

Use Cases and Examples

The Data Mapper Pattern is particularly useful in scenarios where:

• Complex Data Transformations: When data needs to be transformed significantly between the domain model and the data source.
• Multiple Data Sources: When an application needs to interact with multiple data sources, such as a database and a web service.
• Decoupled Architecture: When maintaining a clean separation between business logic and data access logic is a priority.

Example: Implementing a Data Layer

Consider an application that manages a collection of books. We can use the Data Mapper Pattern to separate the book management logic from the data persistence logic.

 1struct Book {
 2    let id: Int
 3    var title: String
 4    var author: String
 5}
 6
 7protocol BookMapper {
 8    func find(byId id: Int) -> Book?
 9    func save(_ book: Book)
10    func delete(_ book: Book)
11}
12
13class DatabaseBookMapper: BookMapper {
14    private var database: [Int: [String: Any]] = [:]
15
16    func find(byId id: Int) -> Book? {
17        guard let data = database[id],
18              let title = data["title"] as? String,
19              let author = data["author"] as? String else {
20            return nil
21        }
22        return Book(id: id, title: title, author: author)
23    }
24
25    func save(_ book: Book) {
26        database[book.id] = ["title": book.title, "author": book.author]
27    }
28
29    func delete(_ book: Book) {
30        database.removeValue(forKey: book.id)
31    }
32}

Design Considerations

When implementing the Data Mapper Pattern, consider the following:

• Complexity: The pattern can introduce additional complexity, especially in simple applications where the Active Record Pattern might suffice.
• Performance: Ensure that the data mapper is optimized for performance, particularly when dealing with large datasets.
• Testing: The separation of concerns makes it easier to test business logic independently of data access logic.

Try It Yourself

To gain a deeper understanding of the Data Mapper Pattern, try modifying the code examples:

• Add additional fields to the User and Book models and update the data mapper implementations accordingly.
• Implement a new data mapper for a different domain model, such as an Order or Product.
• Experiment with different data sources, such as a file-based storage system or a web API.

Knowledge Check

• Explain the primary intent of the Data Mapper Pattern.
• How does the Data Mapper Pattern differ from the Active Record Pattern?
• What are some scenarios where the Data Mapper Pattern is particularly useful?

Embrace the Journey

Remember, mastering design patterns is a journey. The Data Mapper Pattern is just one tool in your toolbox for creating robust and maintainable Swift applications. Keep experimenting, stay curious, and enjoy the process of learning and applying design patterns in your projects.

Quiz Time!