传统三层结构和MVC之于贫血模式和充血模式以及领域建模

         相信很多人跟我一样，一开始在使用贫血模式的三层结构：抽象出来一个贫血的实体封装，然后把对模型的所有操作，分离出来，分离到BLL层去，然后DALL层负责把这些操作和数据库产生映射，负责读写删改的操作。

         后来我开始使用Asp.net MVC来操作。网络上很多理论都是讲究：M是主要数据操作和实体，V 是显示层，一般为模板。而C是一个控制层，或者说调度层，负责把Model跟合适的View结合起来，最终呈现给用户。根据上述理论，我们可以知道V一般为模板，而C其实是很薄的一层，只是一个负责调度。重要的层在M。M完成了所有的业务逻辑，甚至和对数据库的操作都应该如此。而事实上，我下载了很多公开的源码的代码，自己也写了很多代码。最普通的就是依然受到三层结构的影响，把Model进行简单的封装，然后把对手数据库的操作使用EF或者 Linq封装起来，然后再Controller里面完成对数据库封装的调用，最后基本上什么都是写在Controller里面。Controller本来应该成为一个非常薄的一层，而现在变得非常的厚重，而且好几个Action在一个 Controller里面，动辄就上千行。于是乎，大家使用了一个Service层分装起来，然后再Controller里面去调用这些Service和Model。在某种程度上减少了一些Controller的厚度。我当时不知道Service层的时候，甚至抽象出来一个BLL层。

        经过若干个小型项目的开发，我感觉到这样的开发是有一些问题和混乱的，单纯的依靠以前的三层结构是不行的，这个时候需要引入两个概念：领域建模和充血模型。领域建模不一定非要充血模式。比如有本书《领域驱动设计C#2008实现》就是使用了贫血模式来实现的，基本上就是把行为抽象出来作为Service来使用的。而我认为在小项目尚可如此，但是在业务逻辑比较复杂的项目，最好使用充血模式。把行为明确的最为对象的行为，写在领域模型中。Controller直接调用领域层就可以获得对象或者修改对象的状态。对对象之间的操作，或者对象列表等不明确对象的行为的操作可以使用Service来操作，这样业务和关系可以一目了然。

         但是我也在思考几个问题，以前的Model层是单纯的封转的贫血模式，现在如果转化为充血模式，每个对象都携带了一系列的行为和方法，会不会太厚重呢？会不会在大量的列表中呈现出太过笨重，对内存的占用到底比贫血模式差多少呢？处理起来麻烦多少呢？期待有看法的朋友一起商量。