对Repository模式误用的反思和纠正

一直以来想自己做一套开发框架，在其基础上进行快速开发，自从接触微软的MVC框架和Entityframework以来，阅读了大量园子里的相关的技术文章，也进行了不少摸索和尝试，中间经历了多次大刀阔斧的重构，现在总算有了雏形，把权限、模式和界面初步搞定，但是回头一看，依然有很多东西思路不够清晰，很多时候是在生搬硬套，不求甚解，结果搞出来一些四不像的东西。

入行近十年，项目经验和开发经验应当是很丰富的，但是架构方面，确实是个新手，现在总算对相关技术有了一定的了解，因此打算从头再来一遍梳理，彻底的重构。
    之前参考别人的技术文章，加上自己的摸索，大致采用的模式是这样的，使用了MVC和Entityframework，Unity作为IOC容器，Model层和View层不必多说， Controller->Service ->Repository，Repository层通过Entityframework来实现数据的增删改查，业务逻辑放在Service层，通过UnitOfWork模式来实现多实体的事务控制，Controller层的职责就是调度，处理从UI层传过来的参数转换。

首先来说Repository层，首先定义了一个泛型接口，IRepository<Entity>，在里面定义了增删改查，然后定义了一个类
Repository<Entity>，实现IRepository<Entity>接口，同时为了考虑各实体特有的实现，为每个实体定义一个特有接口，以人员为例，定义IUserRepository接口，继承IRepository<User>，最终定义类UserRepository，继承Repository<User>，并实现IUserRepository接口。

所有的实体都是按照上述模式实现的，使用泛型，主要是实现了代码复用，这种模式在园子里也有不少人是这样用的。

关于Repository的定义和作用，园子里有很多文章提过多次了，在此我引用下(来源)：

Repository是一个独立的层，介于领域层与数据映射层（数据访问层）之间。它的存在让领域层感觉不到数据访问层的存在，它提供一个类似集合的接口提供给领域层进行领域对象的访问。Repository是仓库管理员，领域层需要什么东西只需告诉仓库管理员，由仓库管理员把东西拿给它，并不需要知道东西实际放在哪。

由此可见，Repository是从领域驱动设计中的概念，从我的架构设计来说，并不是领域驱动的，没有聚合根的概念，对于Service层来说，需要一个DAL层来处理数据的存储和查询，因此，我这里使用Repository明显是一个误用。

关于Repository与DAL 区别如下：

Repository是DDD中的概念，强调Repository是受Domain驱动的，Repository中定义的功能要体现Domain的意图和约束，而Dal更纯粹的就是提供数据访问的功能,并不严格受限于Business层。

使用Repository，隐含着一种意图倾向，就是 Domain需要什么我才提供什么，不该提供的功能就不要提供，一切都是以Domain的需求为核心；而使用Dal，其意图倾向在于我Dal层能使用的数据库访问操作提供给Business层，你Business要用哪个自己选。换一个Business也可以用我这个Dal，一切是以我Dal能提供什么操作为核心。

这也就意味着，不应当在DAL层单独定义一个IUserRepository类来处理特有的接口方法，如用户不能被删除，而是应当在Service层里做控制，DAL单纯地提供对数据的查询和存储，不关心业务逻辑。

明确了上面的概念，下面就动手进行简化，有两种实现方式，一是使用泛型，二是使用T4模板或者代码生成器，这两种方式都能达到代码复用的目的。我这里采用的泛型，首先定义一个泛型接口IDAO<Entity>，泛型接口中定义方法也很明确：增、删、改、查，此前在IRepository定义了过多的重载方法，例如对于删除，定义了指定主键删除、指定实体删除和指定Lambda表达式删除，对于查询，定义了返回所有实体集合和返回单页数据集合。上述概念明确后，DAL层仅需要提供必要的几个方法即可，而对于同样功能的方法重载，放到Service层更合适。然后定义EFDAO<Entity>类实现该接口。这样做的好处不仅代码实现了复用，而且做到了面向接口编程，对于Service层来说，看到的只是IDAO接口，而不是具体的实现类。而IDAO是怎么实现的，是EntityFramework、NHibernate还是原生的sql，则可以灵活替代，变更数据访问层对整个系统无影响。

简而言之，我的框架实质是MVC模式加三层架构的结合体，View和Controller层基本不动，Model层细分为Model、Service/BLL、DAL三层。

以上是个人的反思和总结，把个人的误用经历、重构原因和最终实现方式发出来，供同道中人参考，欢迎批评指正，期待交流。