1 / 13

D omain and Persistence Patterns

D omain 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

Download Presentation

D omain and Persistence Patterns

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Domain and Persistence Patterns

  2. Fundamental Pattern Types Design Patterns Business Logic Patterns

  3. Business Logic Patterns 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 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

More Related