Repository Entities Confusion

Repository Entities Confusion

EF Repositories vs. Custom Repositories vs. Entities vs. DTOs vs. DAOs

Separation of Domain Logic & Persistence Logic

Entity Repositories & Entities are bit confusing here in asp.net mvc

Entities == Traditional DTOs without Logic or Behavior in Anemic Domain Model

Entity Repositories == Traditional DAOs those provide persistence logic for the DTOs

Db.Context.Repositories should not be used directly we should wrap them into their own classes and then use them.

Using DBContext given repositories directly in the Application Service Layer or Domain Services is not recommended. But in simple CRUD scenarios it could be done.

1.    Entity Repository Classes given by the DBContext, should not be used directly but in simple scenarios can be used directly

2.    Custom defined Wrapper Entity Repository Classes that wraps DBContext inside it and deliver the Persistence Logic for an Entity.

When we put our Entities (DTOs) Collection inside the Application DBContext, we define Entity Repositories (DAOs) for doing persistence of relevant Entities DTOs.

When we put our Entities (DTOs) Collection inside the Application DBContext, IT DOES NOT ADD FUNCTIONALITY OR METHODS TO THE ENTITIES ITSELF.

Entities hold the Domain Logic and the Repositories hold the Persistence Logic

DBContext.EnitityRepository gives us lot of functionality. We are expected to use sub set of that functionality. It is better to wrap these repositories into their own Entity Specific Repository Class (DAO)

Domain Model Project hold the both Definition or Entities (DTOs) and the Interface for the Custom Entity Wrapper Classes (Entity specific DAO classes)

Command

View è Routing Engine è Controllers (WriteViewModel) è Application Services ====

Queries

View ç Presenter ç Controllers (ReadViewModel) çApplication Services ====

DBContext is only interested in Properties/Data Values of Entities. It take them and create the DB Table for Entities.

DBContext return the Repositories around the Entities. Repository are equivalent to the DAO and contain the Persistence Logic. Entities hold the Domain Data and Domain Logic and they are equivalent to the DTO.

Repositories have nothing to do with the Domain Methods and Domain Logic.

We annotate Domain Objects with the Data Annotations and Fluent APIs to tell EF, how these Entities should be mapped to the Database Schema.

It also defines the complex relations ships between entities.

Between EF and Domain Model, Naming Conventions are also there.

Certain Naming Conventions are reflected in certain way in the database.

Such Default Naming Conventions should be known.

So we have 3 levels. 1. Default Conventions. 2. Data Annotations 3. Fluent APIs.

With EF, we do not have to write DAO Classes for the DTOs. It is automatically provided.

With EF, we do not have to write Repository Classes for the Entities. It is automatically provided to us. Entities è EF è Repositories

EF provided Repositories can be directly used in Application Services for simple CRUD applications.

EF provided Repositories should not be used in Application Services for Complex Domains. EF provided Repositories should be wrapped inside the Custom Defined Entity Repositories.

In complex application, Inner Domain Model contains the Entities and Interfaces for the Custom Entity Repositories.

Inner Domain Model do not contain the Persistence Logic, but it contain interfaces for the Persistence Logic.

Custom Repositories are defined in the separate Project. Project also includes the DB Context. Usually this is the .Data project. Or .Persistence project. This project is part of the Outer Domain Model.

Inner Domain Model contains Entities, VO. Aggregate root, domain events.

Outer Domain Model contains Repository, Domain Services, and Factories. Outer Domain model project include the inner Domain Model project.

Application Services needs reference to the Custom Entity Repository.

Application Services use the Interfaces defined in Inner Domain Model to access the Repository. Repository implementation is done in the separate project and provided with in the Application Services by DI/IOC container.