Fowlers Data Access Layer patterns

Question

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?

• Sean McSomething: You tagged your question as VB.NET - some people argue that design patterns are missing language features. Fowler's book is quite dated and ties to using older development environments. Don't take it as scripture.
• Marjan Venema: @SeanMcSomething: Nothing should be taken as scripture, but I wouldn't call Fowler's book dated. The information is still quite valid and useful. That the examples in Fowler's book are tied to older development environments doesn't detract anything from its usefulness. "design patters are missing language features" is an interesting notion. The fact that the patterns Fowler describes are still very much alive and used today, must then mean that most languages have still not caught up with all the evolving requirements that software development puts on them.
• w0051977: @Marjan Venema, thanks. That is what I thought. Are you able to post an answer so that I can give some credit?
• Marjan Venema: thanks, credit is nice, but I don't see how my comment answered your question?
• w0051977: @Marjan Venema, I thought your perspective would lead to a good answer. I agree that your comment did not actually answer the question. Are you ale to answer the question?

Answer 1

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.

• AgostinoX: You make some distinctions that I couldn't find in "Pattern of Enterprise Application Architecture" by Fowler. In particular, I too understand from that book that domain logic and business logic are used interchangeably. At page 20 I read: "The remaining piece is the domain logic, also referred to as business logic".
• AgostinoX: About "Active Record", in "Pattern of Enterprise Application Architecture" by Fowler, at page 160, "The essence of an Active Record is a Domain Model in which the classes match very closely the record structure of an underlying database. Each Active Record is responsible for saving and loading to the database and also for any domain logic that acts on the data". So Active Record is not (only) a data source pattern.