前言
我们进行linq to sql和ef时代后，底层的实现基本使用的是repository模块，即仓储模式，事实上就是把ORM实体的最基本操作进行封闭，对外层不公开操作实现的细节。
面向接口的编程
一个规定，多个实现，这可能是接口给我们带来的最直观的印象了，比如一个仓储在定义后，你可以用linq to sql实现它，也可以用ef去实现它，再或者使用ado.net去实现它，但它对外暴露的永远是稳定的接口，这里我们称为IRepository。
仓储接口是否应该设计成基础操作接口和扩展操作接口
这是今天说的重点，我们把仓储的最基本操作提炼出来，放到IRepository接口里，它叫做基本操作接口；将集合操作及其它附加操作放在IExtensionRepository接口里，我们称它为扩展操作接口；而我们再建立一个完成功能的接口ICompleteRepository，它会集成前两个接口，当调用方要求使用IRepository和IExtensionRepository的功能时，我们必须使用ICompleteRepository去声明对象，而简单的操作我们只需要使用IRepository去声明对象即可。
IRepository接口我们可以这样定义：
public interface IRepository<TEntity> where TEntity : class { /// <summary> /// 添加实体并提交到数据服务器 /// </summary> /// <param name="item">Item to add to repository</param> void Insert(TEntity item); /// <summary> /// 移除实体并提交到数据服务器 /// 如果表存在约束，需要先删除子表信息 /// </summary> /// <param name="item">Item to delete</param> void Delete(TEntity item); /// <summary> /// 修改实体并提交到数据服务器 /// </summary> /// <param name="item"></param> void Update(TEntity item); /// <summary> /// Get all elements of type {T} in repository /// </summary> /// <returns>List of selected elements</returns> IQueryable<TEntity> GetModel(); /// <summary> /// 根据主键得到实体 /// </summary> /// <param name="id"></param> /// <returns></returns> TEntity Find(params object[] id); }
对于扩展的功能接口，我们可以这样去定义：
/// <summary> /// 扩展的Repository操作规范 /// </summary> public interface IExtensionRepository<TEntity> where TEntity : class { /// <summary> /// 添加集合 /// </summary> /// <param name="item"></param> void Insert(IEnumerable<TEntity> item); /// <summary> /// 修改集合 /// </summary> /// <param name="item"></param> void Update(IEnumerable<TEntity> item); /// <summary> /// 删除集合 /// </summary> /// <param name="item"></param> void Delete(IEnumerable<TEntity> item); /// <summary> /// 扩展更新方法，只对EF支持 /// </summary> /// <param name="entity"></param> void Update(System.Linq.Expressions.Expression<Action<TEntity>> entity); /// <summary> /// 根据指定规约得到延时结果集 /// </summary> /// <param name="specification"></param> /// <returns></returns> IQueryable<TEntity> GetModel(Commons.Entity.Specification.ISpecification<TEntity> specification); /// <summary> /// 根据指定lambda得到延时结果集 /// </summary> /// <param name="predicate"></param> /// <returns></returns> IQueryable<TEntity> GetModel(System.Linq.Expressions.Expression<Func<TEntity, bool>> predicate); /// <summary> /// 根据指定规约得到实体 /// </summary> /// <param name="specification"></param> /// <returns></returns> TEntity Find(Commons.Entity.Specification.ISpecification<TEntity> specification); /// <summary> /// 根据指定lambda得到实体 /// </summary> /// <param name="predicate"></param> /// <returns></returns> TEntity Find(System.Linq.Expressions.Expression<Func<TEntity, bool>> predicate); }
而为了使业务层即有IRepository而且还有IExtensionRepository接口的功能，我们将建立一个完整操作的接口，它由仓储实现基类去集成，在业务层，可以声明
这个完整的仓储接口：
/// <summary> /// 完整的数据操作接口 /// 完整的接口中，包括两个事件 /// </summary> public interface ICompleteRepository<T> : IRepository<T>, IExtensionRepository<T> where T : class { /// <summary> /// Occurs after data saved /// </summary> event EventHandler<SavedEventArgs> AfterSaved; /// <summary> /// Occurs before data saved /// </summary> event EventHandler<SavedEventArgs> BeforeSaved; }
一个仓储基类将去实现它，当然你的仓储基类根据ORM不同，可以会有多个版本，你可以配合IOC来动态干这件事，呵呵！
如图：
再看一下传统DAL层图：（比较喜欢DDD架构，对于简单业务还是可以使用这种传统架构的）
好了，今天的仓储接口就讨论到这里吧，呵呵，对于一个问题的答案，在不同的场合，环境下很可能是不同的，而我们的架构也应该根据不同的业务需求，灵活去应对，这样，才会设计出更合理的架构！
本文转自博客园张占岭（仓储大叔）的博客，原文链接：这样设计是否更好些~仓储接口是否应该设计成基础操作接口和扩展操作接口，如需转载请自行联系原博主。