We are using Data Mapper + Domain Model + Service Layer + Repository + UOW from MF Patterns of EAA in the modern OCH based Applications and Frameworks.
Julie Lermen has identified 5 Pattern to encapsulate the Data Access Code. All these Patterns are based on Repository and UOW.
Patterns 1, 2, 3 are DB Schema/CRUD oriented Repositories.
That means for CRUD domains, the UI, Service, Domain Model is CRUD oriented or we can say Data base Table/View oriented.
Domain Model is Anemich Domain Model
Services are just thin Methods call delegating.
View, ViewModels and Controller are CRUD oriented.
Consequently the Persistent Classes or Data Access Classes are also CRUD oriented. Mostly Generic Repository do the work for simple CRUD forms. For Slighy Complex Surrogate Tables we have CusomRepo extending GenricRep. and defined some methods. Generic Repo should not try ot all CRUD sceanrios. We should leave room for Custom Scenario. Do not try to do every with GenricREpo.
I THINK, IN ABOVE CASE WE DO NOT NEED TO SEGREGATE THE COMMAND AND QUERIES. ONLY ONE VIEWMODEL, CONTROLLER, SERVICE, DOMAIN MODEL, REQUEST/RESOPONE MODEL @ AS LAYER WILL DO THE WORK
Pattern 4, 5 are Business Scenario/UI Screen/Domain Oriented Scenarios
In pattern 4, 5, things are lot mixed up. orchestratin is involved. all things are Feature oriented.
Including the 4, 5 Data Access Patterns, the EF is all about the
Repository and UOW pattern. There is nothing more than that.
Julie Lermen has identified 5 Pattern to encapsulate the Data Access Code. All these Patterns are based on Repository and UOW.
Patterns 1, 2, 3 are DB Schema/CRUD oriented Repositories.
That means for CRUD domains, the UI, Service, Domain Model is CRUD oriented or we can say Data base Table/View oriented.
Domain Model is Anemich Domain Model
Services are just thin Methods call delegating.
View, ViewModels and Controller are CRUD oriented.
Consequently the Persistent Classes or Data Access Classes are also CRUD oriented. Mostly Generic Repository do the work for simple CRUD forms. For Slighy Complex Surrogate Tables we have CusomRepo extending GenricRep. and defined some methods. Generic Repo should not try ot all CRUD sceanrios. We should leave room for Custom Scenario. Do not try to do every with GenricREpo.
I THINK, IN ABOVE CASE WE DO NOT NEED TO SEGREGATE THE COMMAND AND QUERIES. ONLY ONE VIEWMODEL, CONTROLLER, SERVICE, DOMAIN MODEL, REQUEST/RESOPONE MODEL @ AS LAYER WILL DO THE WORK
Pattern 4, 5 are Business Scenario/UI Screen/Domain Oriented Scenarios
In pattern 4, 5, things are lot mixed up. orchestratin is involved. all things are Feature oriented.
Including the 4, 5 Data Access Patterns, the EF is all about the
Repository and UOW pattern. There is nothing more than that.
No comments:
Post a Comment