Fowlers Data Access Layer patterns

design-patternsenterprise-architecture

Fowler talks about a number of design patterns available for the data access layer e.g. Table Data Gateway, Row Data Gateway, Active Record and Data Mapper.

In the book it suggests using Data Mapper with Transaction Script and Active Record with Domain Model. This doesn't seem to be logical to me as Transaction Script classes contain business logic and data logic and domain model separates business logic and data logic. Active Record combines business logic and data logic (like Transaction Script rather than domain model) and Data Mapper separates business logic and data logic (like domain model rather than Transaction Script). What am I not understanding here?

Best Answer

Point 1 Patterns are a means to simplify communication about various concepts. Patterns are not intended to be used as LEGOs where they snap together and solve problems. Combinations of concepts may help resolve a problem, but you should not expect to be able to simply pick and choose patterns for your needs. First and foremost, they are a communication aid.

Point 2 Domain logic != Business logic, and I think this is the crux of your misunderstanding.

Per Fowler:
Active Record and Data Mapper are Data Source Architectural Patterns.
Transaction Script and Domain Model are Domain Logic Patterns.

And he defines them as:

Active Record

An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.

Data Mapper

A layer of Mappers (473) that moves data between objects and a database while keeping them independent of each other and the mapper itself.

Transaction Script

Organizes business logic by procedures where each procedure handles a single request from the presentation.

Domain Model

An object model of the domain that incorporates both behavior and data.

You mentioned that Fowler suggests using

  • Data Mapper with Transaction Script
  • Active Record with Domain Model

and that you didn't understand the following aspects.

Transaction Script classes contain business logic and data logic

Which isn't correct. Transaction script groups together similar business logic and doesn't say anything about data logic.

Domain Model separates business logic and data logic

Domain Model doesn't address business logic or data logic. It puts together rules that are domain specific. Those could be considered business rules, but they're not. Domains have inherent rules to them that all businesses must conform to. External regulation is a good example of domain logic that is not necessarily business logic, but still rules that must be conformed to.

Active Record combines business logic and data logic

No, Active Record merely deals with data logic and provides a wrapper around what may be a very complicated storage mechanism for the data. No business logic here.

Data Mapper separates business logic and data logic

Factually, this is true, but that's disingenuous for this question. Data Mapper is an isolation layer. It would be a useful approach if there were multiple data sources to glom together.

Related Topic