关于架构设计的“贫血模型”与“充血模型”
初识“贫血模型”与“充血模型”，是在李刚老师（不是那个官二代他爹…..）的《轻量级J2EE开发实践》中，它们是面向对象程序设计对实体（Entity）建模的两种方式。对于需求分析得到的Entity，首先面临的问题是如何构建Domain Object（领域模型）。贫血模型与充血模型给出了两种不同的方案：
贫血模型：是指领域对象里只有get和set方法，或者包含少量的CRUD方法，所有的业务逻辑都不包含在内而是放在Business Logic层。
充血模型：层次结构和上面的差不多，不过大多业务逻辑和持久化放在Domain Object里面，Business Logic（业务逻辑层）只是简单封装部分业务逻辑以及控制事务、权限等。
简而言之，贫血模型下，Domain Object只是个保存相关属性的马甲，其中的内容需要Business Logic注入，而充血模型下，Domain Object既有肉体（属性）也有灵魂（业务逻辑），Business Logic只是其逻辑的简单封装。
图灵社区上的讨论给出了贫血模型与充血模型的优缺点：
这种贫血的模型好处是：
1、每个贫血对象职责单一，所以模块解藕程度很高，有利于错误的隔离。
2、非常重要的是，这种模型非常适合于软件外包和大规模软件团队的协作。每个编程个体只需要负责单一职责的小对象模块编写，不会互相影响。
贫血模型的坏处是：
1、由于对象状态和行为分离，所以一个完整的业务逻辑的描述不能够在一个类当中完成，而是一组互相协作的类共同完成的。因此可复用的颗粒度比较 小，代码量膨胀的很厉害，最重要的是业务逻辑的描述能力比较差，一个稍微复杂的业务逻辑，就需要太多类和太多代码去表达(针对我们假定的这个简单的工时管 理系统的业务逻辑实现，ruby使用了50行代码，但Java至少要上千行代码)。
2、对象协作依赖于外部容器的组装，因此裸写代码是不可能的了，必须借助于外部的IoC容器。
充血模型的好处是：
1、对象自洽程度很高，表达能力很强，因此非常适合于复杂的企业业务逻辑的实现，以及可复用程度比较高。
2、不必依赖外部容器的组装，所以RoR没有IoC的概念。
充血模型的坏处是：
1、对象高度自洽的结果是不利于大规模团队分工协作。一个编程个体至少要完成一个完整业务逻辑的功能。对于单个完整业务逻辑，无法再细分下去了。
2、随着业务逻辑的变动，领域模型可能会处于比较频繁的变动状态中，领域模型不够稳定也会带来web层代码频繁变动。
我在设计XueBa时，采用了“贫血模型”的设计思路，具体原因有下：
1． 贫血模型使得Domain Object小巧精炼，便于维护；
2． 项目的业务逻辑严重依赖于数据库操作，由于Business Logic同时封装了DAL（Data Access Layer）（原因是项目总体代码量不大），将业务逻辑放在Business Logic里自然顺理成章
3． 如上所述，贫血模型适合团队协作，尤其适合我们这种半瓶醋性质的团队~
举个例子，依照贫血模型，我将Domain Object之一——Document类设计如下：
namespace XueBa.Entity
{
public class Document : ITagable
{
public Document()
{
Tags = new List<Tag>();
}
public int Id { get; set; }
public int FieldId { get; set; }
public User Poster { get; set; }
public string Title { get; set; }
public int TypeId { get; set; }
public Author Author { get; set; }
public Institution Institution { get; set; }
public DateTime PostDateTime { get; set; }
public int Views { get; set; }
public List<Tag> Tags { get; set; }
}
}
它很像一个POJO（Plain and Old Java Object），微软是否也应该发明下POCO（Plain and Old C# Object）？
相应的，对应一个DocumentManager（Business Logic & DAL）：
namespace XueBa.SqlServer
{
public class DocumentManager
{
public DocumentManager()
{
}
public Document GetDocumentById(int id)
{
......
}
private Document fillDocument(SqlDataReader reader)
{
.......
}
public List<Document> GetDocumentByRange(int pageNum)
{
.......
}
public List<Document> GetPopularDocuments(int num)
{
.....
}
}
}
由于业务逻辑并不复杂，因此这样的设计时可行的。
