【Yom框架】漫谈个人框架的设计之【是IRepository还是IRepository<T>】？
前言
对于仓储Repository的设计，其实很多人都很纠结，因为从广义来说，Repository有两种类型：
IRepository和IRepository<T>
框架的重构想得最多的最重要的几个问题：
1：解耦（每层可以替换其他的，比如换一个UI层可以把Web 项目快速转换成Winform项目）
2：扩展性（可以灵活抹去框架的某个层，让其他的第三方框架依据自己的接口实现该层的逻辑，其它层不变，也就是插拔式扩展）
3：灵活（开发便捷，使用灵活）
4：维护性（别人了解框架后，可以让别人无障碍维护）
........
-------------------------------------
题外话不多说 马上进入辩证主题：是IRepository还是IRepository<T> ？
------------------------------------
首先看IRepository<T>
IRepository<T>接口定义形式如下(其中IEntiry是一个实体类接口)：
1 public interface IRepository<T> where T : Entity.IEntity 2 { 3 T FindBy(string primaryKey); 4 IEnumerable<T> FindAll(); 5 IEnumerable<T> FindAll(string where); 6 IEnumerable<T> FindAll(string where, string order); 7 IEnumerable<T> FindAll(int pageIndex, int pageSize, string where, string order, out int count); 8 void Add(T entity); 9 void Delete(T entity); 10 void DeleteAll(); 11 void DeleteAll(string where); 12 void DeleteAll(System.Collections.IEnumerable pkValues); 13 void Update(T entity); 14 bool Exists(string primaryKey); 15 }
可以看见，IRepository和接口IEntity通过泛型T结合在了一起，形成了耦合
IRepository<T> 可以通过T操作IEntity
开发的时候，每个IEntity的子类都得对应一个IRepository<T>的子类，如:
public class DepartmentRepository : Repository.RepositoryBase<Entity.Department.Department> { }
其中Department是IEntity的一个子类
而RepositoryBase<T>是一个真正可用的仓储父类(此类假设已通过第三方或者自己的ORM框架实现了数据库操作)
------------------------------------
再看IRepository接口
------------------------------------
IRepository接口的设计：
public interface IRepository { #region 实体相关接口 TEntity FindBy<TEntity>(IEnumerable<string> primaryKey) where TEntity : IEntity; IEnumerable<TEntity> FindAll<TEntity>() where TEntity : IEntity; IEnumerable<TEntity> FindAll<TEntity>(string where, params System.Data.IDataParameter[] ps) where TEntity : IEntity; IEnumerable<TEntity> FindAll<TEntity>(string where, string order, params System.Data.IDataParameter[] ps) where TEntity : IEntity; IEnumerable<TEntity> FindAll<TEntity>(int pageIndex, int pageSize, string where, string order, out int count, params System.Data.IDataParameter[] ps) where TEntity : IEntity; void Add<TEntity>(TEntity entity) where TEntity : IEntity; void Delete<TEntity>(TEntity entity) where TEntity : IEntity; void DeleteAll<TEntity>() where TEntity : IEntity; void DeleteAll<TEntity>(string where, params System.Data.IDataParameter[] ps) where TEntity : IEntity; void DeleteAll<TEntity>(IEnumerable<IEnumerable<string>> pkValues) where TEntity : IEntity; void Update<TEntity>(TEntity entity) where TEntity : IEntity; bool Exists<TEntity>(IEnumerable<string> primaryKey) where TEntity : IEntity; #endregion #region 原始数据操作接口 int ExecuteSql(string sql, params System.Data.IDataParameter[] ps); object ExecuteScalar(string sql, params System.Data.IDataParameter[] ps); System.Data.DataTable ExecuteDataTable(string sql, params System.Data.IDataParameter[] ps); #endregion }
这种接口的设计就是把ReopositoryBase<T>里的T放入接口的方法中，
让泛型方法操作对应的实体类
这种接口的设计可以很好地实现Repository共用
也就是说整个项目只要一个通过ORM实现了的RepositoryBase类就可以操作所有的持久层实体对象
不用每个实体类都对应一个IRepository
大大的减少了项目开发的便捷性
对于业务逻辑，新增一个Server层
Server层，让每个Server类对应一个实体类的逻辑,如：假设有Class Aa 则必须有 Class AaServer对应
而Server就调用RepositoryBase类操作Server类对应的实体
--------------------------------------
总结：
其实不管是IRepository还是IRepository<T> 都各自有各自的优势
IRepository<T>的子类对实体类是很专注的，它只可以操作一个实体类，对它的修改不会影响到其他实体来的操作
从而可以实现对应实体类的个性化拓展，而IRepository可以操作所有的实体类，修改了子类则会影响所有的实体的操作
虽然如此，在开发过程中，难免会有在某个业务层操作其他对象的需要
如果是IRepository<T>，那么必须在业务层New很多其他实体类对应的IRepository<T>子类对象出来
这对于解耦是个大忌，也就是说Repository层和Server层已经高度耦合了。
也正因为这个原因我个人更倾向于IRepository，抛弃Repository层，只让一个可以操作所有所有实体的Repository存在就可以了
更重要的原因是Repository层相对拉来说，接口比较稳定，一般的项目，没有必要扩展IRepository接口的操作。
所以IRepository接口一个重要的优势是：
在某个实体类的Server层可以用IRepository类的方法，不需要New额外的对象就可以操作其他实体类，
只要在【Repository.方法<T>】里的T换成其他实体类就可以了
如果换成IRepository<T>实现,则需要在该实体类的Server层New很多其他实体类对应的IRepository<T>才可以操作其他实体类的对象，这对解耦来说是大忌。所以正是因为这个原因，我宁愿选择IRepository，而不是IRepository<T>
---------------------
题外话
上面的IRepository接口已经被我再次抛弃了
抛弃原因如下：
1：接口的组合主键扩展性差，也就是说主键会受制于ORM框架的实现
2：不支持搜索和排序解耦
所以建议自己好好设计IRepository接口
-------------------------------------
完