关于架构设计的“贫血模型”与“充血模型”

初识“贫血模型”与“充血模型”，是在李刚老师（不是那个官二代他爹…..）的《轻量级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)
        {
            .....
        }
    }
}

由于业务逻辑并不复杂，因此这样的设计时可行的。

在此，想问邹欣老师一个问题：微软在项目开发时，最常用的是哪一种？