前言
对于仓储Repository的设计，其实很多人都很纠结，因为从广义来说，Repository有两种类型：
IRepository和IRepository<T>
框架的重构想得最多的最重要的几个问题：
1：解耦（每层可以替换其他的，比如换一个UI层可以把Web 项目快速转换成Winform项目）
2：扩展性（可以灵活抹去框架的某个层，让其他的第三方框架依据自己的接口实现该层的逻辑，其它层不变，也就是插拔式扩展）
3：灵活（开发便捷，使用灵活）
4：维护性（别人了解框架后，可以让别人无障碍维护）
........
-------------------------------------
题外话不多说 马上进入辩证主题：是IRepository还是IRepository<T> ？
------------------------------------
首先看IRepository<T>
IRepository<T>接口定义形式如下(其中IEntity是一个实体类接口)：
public interface IRepository<T> where T : Entity.IEntity
{
T FindBy(string primaryKey);
IEnumerable<T> FindAll();
IEnumerable<T> FindAll(string where);
IEnumerable<T> FindAll(string where, string order);
IEnumerable<T> FindAll(int pageIndex, int pageSize, string where, string order, out int count);
void Add(T entity);
void Delete(T entity);
void DeleteAll();
void DeleteAll(string where);
void DeleteAll(System.Collections.IEnumerable pkValues);
void Update(T entity);
bool Exists(string primaryKey);
}
可以看见，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
}
这种接口的设计就是把IReopository<T>里的T放入接口的方法中，
让泛型方法操作对应的带入泛型实体类
IReopository接口的设计可以很好地实现Repository共用
也就是说整个项目只要一个通过ORM实现了的RepositoryBase类就可以操作所有的持久层实体对象
不用每个实体类都对应一个Repository
大大的减少了项目开发的繁杂性
对于业务逻辑，新增一个Server层让每个Server类对应一个实体类的逻辑
如：假设有Class Aa 则必须有 Class AaServer对应
而Server就调用RepositoryBase类操作Server类对应的实体
--------------------------------------
总结：
其实不管是IRepository还是IRepository<T> 都各自有各自的优势：
1、IRepository<T>的子类对实体类是很专注的，它只可以操作一个实体类，对IRepository<T>的子类的修改不会影响到其他实体类的操作
从而可以实现对应实体类的个性化拓展；
2、IRepository可以操作所有的实体类，修改IRepository的子类则会影响所有的实体的操作
虽然如此，在开发过程中，难免会有在某个业务层XxServer操作其他实体类的需要
如果是用IRepository<T>仓储，那么必须在业务层XxServer中New很多其他实体类对应的IRepository<T>的子类对象出来
这对于Repository与Server的解耦是个大忌，也就是说Repository层和Server层已经高度耦合了。
也正因为这个原因我个人更倾向于IRepository，并抛弃Repository层(如果是每个实体对应一个Repository,那么将需要一个Repository层)，
只让一个可以操作所有所有实体的Repository存在就可以了
更重要的原因是Repository层相对来说，接口比较稳定，一般的项目，没有要扩展IRepository接口操作的需要。
所以IRepository接口一个重要的优势是：
在某个实体类的Server层可以统一用IRepository类的方法实现业务，
不需要像IRepository<T>实现方式一样，New额外的对象就才可以操作其他实体类，
只要在【Repository.方法<T>】里的T换成其他实体类就可以了
这对解耦来说是有好处的。
所以正是因为这个原因，我选择IRepository，而不是IRepository<T>
---------------------
题外话
上面的IRepository接口已经被我再次抛弃了
抛弃原因如下：
1：接口的组合主键扩展性差，也就是说主键会受制于ORM框架的实现
2：不支持搜索和排序解耦
至于新的IRepository接口 将在下篇文章给出
-------------------------------------
完