团队开发框架核心架构—Repositories
Repository由来
- 数据库只是对象的永久保存方式，就象我们打字时经常需要存盘一样，我们不能因为要“存盘”而去关心“存盘文件格式(数据表结构)”。
- 我们应该更聚焦在模型这个对象，把所有对象的保存(冬眠)和调用(激活)交由Respository完成。
- 对象保存到数据库交由专门的Repository仓储来完成，由Repository负责如何将对象分解成数据库能够保存的格式。
什么是仓储
仓储表示聚合的集合。
仓储所表现出来的集合外观，仅仅是一种模拟，除了测试以外，没有理由使用内存中真正的集合来创建仓储。
不应该为所有实体建立仓储，只有聚合才拥有仓储。
仓储用来重建已持久化的聚合，而工厂用于新建聚合。
使用仓储的优点
直接使用Entity Framework的DbContext不是很好吗，为什么还要在DbContext的上方封装一层仓储呢，这是否多此一举？
很多使用EF的程序员确实是直接使用DbContext，并且他们发现开发起来十分简单，因为DbContext的接口设计得非常优雅，从接口上看，DbContext就好像所有实体集合的仓库。
另一方面，很多使用了仓储的朋友，都是依葫芦画瓢，虽然创建了仓储，但并没有体会到多大好处。
下面简要介绍使用仓储将为你带来的优点。
从概念上简化数据操作
仓储模拟了某种聚合的集合，而DbContext包含了N种类型的集合。
与仓储相近的一个数据访问模式是数据访问对象（DAO）模式，很多人认为仓储不过是数据访问对象换了一个名词而已，从技术上说的确如此，仓储的强大之处在于概念上更简单。仓储在概念上代表内存中的集合操作，而数据访问对象代表数据库操作，很明显，集合比数据库在概念上更简单。减少冗余查询逻辑
如果直接使用DbContext，由于特定查询逻辑没有一个固定位置，可能分散到任何地方，这很容易造成冗余。
仓储是封装特定查询逻辑的好地方，对于特定的查询逻辑，放到与聚合相应的仓储中即可。降低耦合度
直接使用DbContext，所有调用代码与EF实现高度耦合。
另一方面，由于DbContext能够获取任意实体，这些实体可能位于聚合内部，这样会破坏聚合的封装性，同时在任意位置可以获取任意对象，由于缺乏约束力而导致更高的耦合。方便单元测试
直接使用DbContext只能进行集成测试，必须连接到真实数据库。而领域层只持有仓储接口，所以测试时很容易替换成模拟实现，从而避开数据库。
IRepositoryBase.cs
using System;
using System.Collections.Generic;
using System.Linq;
using System.Linq.Expressions;
using System.Threading.Tasks;
namespace Rdf.Domain.Repositories
{
/* Note: ChenQP
* 定义仓储接口
* 通过仓储模式，可以更好把业务代码与数据库操作代码更好的分离，可以针对不同的数据库有不同的实现类，而业务代码不需要修改。
* 定义仓储接口的代码写到Domain项目中，因为仓储接口是领域层的一部分。
*/
public interface IRepositoryBase<T> where T : class
{
#region On C、U、D、Before&After
void OnBeforeInsert(T entity);
void OnAfterInsert(T entity);
void OnBeforeUpdate(T entity);
void OnAfterUpdate(T entity);
void OnBeforeDelete(T entity);
void OnAfterDelete(T entity);
#endregion
#region 获得实体的列表
List<T> GetAllList();
Task<List<T>> GetAllListAsync();
Task<List<T>> GetAllListAsync(Expression<Func<T, bool>> predicate);
IQueryable<T> GetAll();
IQueryable<T> GetAll(Expression<Func<T, bool>> predicate = null);
#endregion
#region 获取实体的列表，支持分页
IEnumerable<T> Get(string orderBy, int pageIndex, int pageSize);
IEnumerable<T> Get(Expression<Func<T, bool>> predicate, string orderBy, int pageIndex, int pageSize);
#endregion
#region 获得单个实体
T Single(Expression<Func<T, bool>> predicate);
Task<T> SingleAsync(Expression<Func<T, bool>> predicate);
T FirstOrDefault(Expression<Func<T, bool>> predicate);
Task<T> FirstOrDefaultAsync(Expression<Func<T, bool>> predicate);
#endregion
#region 插入
T Insert(T entity);
Task<T> InsertAsync(T entity);
#endregion
#region 更新
T Update(T entity);
Task<T> UpdateAsync(T entity);
#endregion
#region 删除
void Delete(T entity);
Task DeleteAsync(T entity);
void Delete(Expression<Func<T, bool>> predicate);
Task DeleteAsync(Expression<Func<T, bool>> predicate);
#endregion
#region 其他
int Count();
Task<int> CountAsync();
int Count(Expression<Func<T, bool>> predicate);
Task<int> CountAsync(Expression<Func<T, bool>> predicate);
long LongCount();
Task<long> LongCountAsync();
long LongCount(Expression<Func<T, bool>> predicate);
Task<long> LongCountAsync(Expression<Func<T, bool>> predicate);
#endregion
}
}
仓储总结
仓储被设计出来的目的，提供一个类似于集合一样的用于管理聚合的容器，封装与数据库打交道的逻辑
工厂用于创建对象，而仓储则用来重建对象
领域模型中只包含仓储的接口定义
仓储一般不负责事务处理
仓储的查询接口设计
- 简单明确固定个数的参数，较常用
- Specification， Criteria，搜索条件动态时
