最佳实践：实体框架：如果使用存储库和UoW模式，在哪里进行联接

Question

I have a user repository and partner repository. My repositories do not return IQuerables. A user entity has a partnerID. I want to use the partnerID to join the two tables user and partner Table by using the repositories using Linq. However I'm not sure where to do these joins. There is no foreign key on partner and user so I cannot do a Include via navigation property.

I know that the joins should not go in the repository. Should the join happen in the UoW? Or a service? What is best practice in terms of where I do these joins?

Answer 1

Aggregate root: https://martinfowler.com/bliki/DDD_Aggregate.html

On your aggregates, which ever is the root would be the name of your repo because

Any references from outside the aggregate should only go to the aggregate root

Answer 2

In our company we separate the object that holds the use cases that must be performed (Unit of Work), from the concept of storing data (Repository) from the method on how data is stored (in a database using entity framework).

Advantages of separating DbContext from Repository

By using this separation it is possible to change the database to anything else that stores tables. For instance, you could use a sequence of CSV-files, or use Dapper to access the database.

Another advantage of separation between Entity Framework and Repository is that you can provide interfaces that don't give access to items that you don't want users to have access to. For instance, some users may only query data, others may add or update data, and only a few may delete objects.

A very nice side effect is that we can unit test the code that uses the repository with a collection of Test Lists instead of real database tables.

Only if new use cases require new data, we need to change all three. Users of our unit of work who don't need the new data won't notice the difference

DbContext

The DbSets in the DbContext represent the tables of our database. Every table has at least an Id as primary key, and a nullable DateTime object that marks the date when an object was declared obsolete. A background process regularly removes all objects that are obsolete for some time.

The latter part is done to prevent that user A is updating a record while user B is deleting the same record. Users can only mark records obsolete, they can't delete them.

interface IDbItem
{
    int Id {get; }      // no need to ever change the primary key
    DateTime? Obsolete {get; set;}
}

For example a Customer:

class Customer : IDbItem
{
     public int Id {get; set;}
     public DateTime? ObsoleteDate {get; set;}

     public string Name {get; set;}
     ... // other properties
}

The DbContext is kept as simple as possible: it only represents the tables and the relations between the tables

Repository

The repository hides which storage method is used to store the data. It could be a database, a series of CSV-files, the data could be divided over several databases.

The repository usually has several interfaces:

• A query-only interface, returning IQueryable<...> of every table that you want to expose. Users of this interface can do every query they want. They can't change data. This has the advantage that you can hide properties and tables that you don't want to expose. Users can't accidently change items.
• An interface to Create / Update items, as well as query. For the few forms that really add or update the database. They can also mark items Obsolete.
• An interface to remove data that was marked Obsolete . Used by a background process to regularly remove obsolete data.

Just like entity framework has classes the represent the entities (tables: customers, orders, order lines, ...) and classes that represent the collection of entities ( IDbSet<Customer> ), the Repository has similar classes and interfaces. Most of them are re-usable and one-liners

Repository Entity Classes

interface IId
{
    int Id {get;}
}

interface IRepositoryEntity : IId
{
    bool IsObsolete {get;}
    void MarkObsolete();
}

Every Repository item can be marked obsolete. A common base class:

class RepositoryEntity<TSource> : IId, IRepositoryEntity
      where TSource : IDbItem
{
     public TSource DbItem {get; set;}

     // Interface IId
     public int Id => this.DbItem.Id;

     // Interface IRepositoryEntity
     public bool IsObsolete => this.DbItem.ObsoleteDate != null;
     public void MarkObsolete()
     {
         this.DbItem.ObsoleteDate = DateTime.UtcNow;
     }
}

For example a Customer:

interface IReadOnlyCustomer : IId
{
    string Name {get;}
    ...
}
interface ICustomer : IRepositoryItem
{
    string Name {get; set;}
}
class Customer : RepositoryEntity<Customer>, IReadOnlyCustomer, ICustomer
{
     // Interfaces IId and IRepositoryItem implemented by base class

     // Interface ICustomer
     public string Name {get; set;}
     ...

     // Interface IReadOnlyCustomer
     string IReadOnlyCustomer.Name => this.Name;
     ...
}

You see that the Repository Customer only needs to implement the Customer properties that you actually want to expose to the outer world. The repository doesn't need to represent your database tables.

For example, if your database has split values for Customer FirstName , MiddleName , FamilyName , then your could concatenate them in the get Name function.

Repository Collections

The Repository collections are similar to IDbSet<...> . There is an interface to Query only , and one to Query, Update, Mark Obsolete . Of course we also have full access, granted to the happy few.

For ReadOnly it is enough to have IQueryable<TEntity> where TEntity : Iid

To query / add / update / Obselete I need an ISet and a Set:

interface ISet<TEntity> : IQueryable<TEntity> where TEntity: IRepositoryEntity
{
     TEntity Add(TEntity item);
}

class Set<TEntity, TDbEntity> : ISet<TEntity>
  where TEntity: IRepositoryEntity,
  where TDbEntity: IDbItem
{
     public IDbSet<TEntity> DbSet {get; set;}

     // implement the interfaces via DbSet
     public TEntity Add(TEntity item)
     {
         // TODO: convert item to a dbItem
         return this.DbSet.Add(dbItem);
     }
     // Similar for IQueryable<TEntity> and IQueryable
}

The interface for ReadOnly access and for CRUD access:

interface IReadOnlyRepository : IDisposable
{
     IQueryable<IReadOnlyCustomer> Customers {get;}
     IQueryable<IReadOnlyOrders> Orders {get;}
}
interface IRepository : IDisposable
{
     ISet<ICustomer> Customers {get;}
     ISet<IOrder> Orders {get;}
     void SaveChanges();
}

Those who have access to the ReadOnlyRepository can only query data. They can't make any changes. Those who have access to IRepository can Add items, Update items and Save the changes.

Class Repository implements all interfaces:

class Repository : IReadOnlyRepository,     // Query Only
 IRepository,                               // Query, Add and Update
 IDisposable
{
     private readonly dbContext = new CustomerDbContext();
     // TODO: Dispose() will Dispose dbContext

     // Used by the other interfaces
     protected IDbSet<Customer> Customers => this.dbContext.Customers;
     protected IDbSet<Orders> Orders => this.dbContext.Orders;
     void SaveChanges() {this.dbContext.SaveChanges();}

     // IRepository:
     ISet<ICustomer> IRepository.Customers => new Set<Customer>{DbSet = this.Customers};
     ISet<IOrder> IRepository.Orders => new Set<Order>{DbSet = this.Orders};
     void IRepository.SaveChanges() {this.DbContext.SaveChanges();}

     // IReadOnlyRepository
     IQueryable<IReadOnlyCustomer> IReadOnlyRepository.Customers => this.Customers;
     IQueryable<IReadOnlyOrders> IReadOnlyRepository.Orders => this.Orders;
}

It seems a lot of code, but most functions are one-liners that call the corresponding entity-framework function.

Finally we need a factory that creates the Repository. If you want to re-use this for several Repositories create a generic factory class. For simplicity I create it for the Ordering database:

class OrdersRepository
{
    public IReadOnlyRepository CreateReadOnly()
    {
         // TODO: if desired check rights: can this user access this database?
         return new Repository();
    }
    public IRepository CreateUpdateAccess()
    {
         // TODO: if desired check rights: can this user access this database?
         return new Repository();
    }
    public Repository CreateFullControl()
    {
         // TODO: if desired check rights: can this user access this database?
         return new Repository();
    }

In fact: for the background process that removes all obsolete items we have a special interface that deletes all items that are obsolete for some time. Not mentioned here anymore.

Usage:

var repositoryFactory = new RepositoryFactory() {AccessRights = ...}

// I need to query only:
using (var repository = repositoryFactory.CreateUpdatAccess())
{
     // you can query, change value and save changes, for instance after a Brexit:
     var customersToRemove = repository.Customers.Where(customer => customer.State == "United Kingdom")
     foreach (var customerToRemove in customersToRemove);
     {
         customerToRemove.MarkObsolete();
     }
     repository.SaveChanges();
}

// I need to change data:
using (var repository = repositoryFactory.CreateReadOnly())
{
     // do some queries. Compiler error if you try to change
}