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?

  • 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. – Sean McSomething Jul 19 '13 at 20:49
  • @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. – Marjan Venema Jul 20 '13 at 10:36
  • @Marjan Venema, thanks. That is what I thought. Are you able to post an answer so that I can give some credit? – w0051977 Jul 20 '13 at 11:07
  • thanks, credit is nice, but I don't see how my comment answered your question? – Marjan Venema Jul 20 '13 at 11:30
  • @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? – w0051977 Jul 20 '13 at 11:33

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.