Five Patterns for Encapsulating EF based Data Access Code

Five Patterns for Encapsulating Data Access EF Code
Five Patterns for Encapsulating Repository & UOW
Five Patterns to Encapsulate Data Access Code
Five Patterns Encapsulate EF Code
Encapsulate EF based Data Access Code
Encapsulate ORM based Data Access Code
Encapsulate Repository based Data Access Code
Pattern for Encapsulating the Data Access EF Code in ASP.NET MVC, Guidance for Selecting the Pattern in different situation
For Simple and Repeatable Inserts Updates and Deletes, Along with Simple Queries, Generic Repository with UOW will be just right for you
Otherwise you Explicit Classes with having explicit Data Access Logic to encapsulate the Data Access Code
Generic Repository for Simple CRUD Work
Explicit Classes for Complex Persistence Needs
Now we have 5 patterns or choices for encapsulating the EF Data Access Code.
This part in Onion Architecture was major source of confusion. Everyone does this in its own way.
When we see different flavors of Encapsulating the Data Access Code with rationale when to use which type of Data Access Code, it causes confusion.
Consulting Martin Fowler Patterns will complete this Data Access Pattern Language.
Pattern 4, and 5 are complex, those can be further divided based on Command and Queries. Commands in on Class and Queries in other Class
Pattern 1, 2, 3 are DB Schema/CRUD oriented Repositories
Pattern 4, 5 are Business Scenario/UI Screen/Domain Oriented Scenarios

We selected the Data Access Pattern, by seeing how FAT the Domain Scenario/Feature is. Request Processing Pipeline for different scenarios.

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. 


Summary 

While Saving the Data After executing the App n Domain Logic
App. Service  ç Interface  ç Data Access Class  ç DBContext  EF  DB

All above patterns are related to Data Access Class that encapsulates the Data Access Code. Its purpose is that DBContext or the Repositories provided by it should not go directly to the App. Service. There should be a wrapper in between. It is also aimed that Domain Services should not be leaked to the Application Service.
Non Repository Solutions
EF is totally based on Repository. All above patterns to encapsulate the Data Access code is based on EF Repository. I guess all other ORMs also work on the base of repository. All ORMs are repository based. ORM save us from the Dirty ADO.NET work we used to do in the past. 

If we go for Non Repository based solutions, then we will have to do all the dirty work of Connection handling, fetching results sets, managing transactions. We will have to work on the deep level.