1. Domain and Persistence Patterns

2. Fundamental Pattern Types Design Patterns Business Logic Patterns

3. Transaction Script Domain Model Table Module

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

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

6. 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.

7. 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

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

9. 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

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

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

12. 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

13. 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