Database Persistence Patterns and Domain Logic Best Practices

Domain and Persistence Patterns

Fundamental Pattern Types Design Patterns Business Logic Patterns

Business Logic Patterns Transaction Script Domain Model Table Module

Transaction Script User Action relates directly to database action Typically CRUD operations Database code is straight-forward Result can be displayed to user

Using Objects Complex business logic can require multiple processing paths, with multiple options Better modeled with classes in domain layer

Table Module Class corresponds to virtual database table Use record or data set Still CRUD operations Good for applications with minimal business logic complexity, but complicated data relationships.

Table Module Issues Applications do not always have a simple relationship with database tables Close coupling of database and business logic Can make evolving the application difficult

Domain Model Model business logic with classes Use interface based polymorphism to partition and layer Object-relational mismatch

Why use Domain Model? Many applications do not stay simple Simple apps will have minimal object-relational mismatches Hard to evolve Transaction Script or Table Module. Domain Modeling: Eric Evans, "Domain Driven Design" Jimmy Nilsson, "Applying Domain-Driven Design and Patterns

Isolating Database Logic Separate Business Logic from Storage Code Persistence Patterns Data Mapper Repository

Data Mapper Pattern Maps Domain Objects to Database Tables Object Relational Mapping (ORM) Simple Implementation in current example ICustomerDataMapper Interface based design Inversion of Control

Repository Pattern Query based on objects, not relational tables Simple criterion query Returns a collection of objects Uses Data Mapping layer Interface based Inversion of Control

Summary Domain patterns are industry specific Persistence patterns separate the business logic from knowledge of how the data is stored Interface based design Data Mapper Pattern Repository Pattern