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

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

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

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

posted @ 2012-11-06 00:41 MagicCode1023 阅读(...) 评论(...) 编辑 收藏