贫血模型和充血模型

一、贫血模型

所谓贫血模型，是指Model 中，仅包含状态(属性），不包含行为(方法），采用这种设计时，需要分离出DB层，专门用于数据库操作。

二、充血模型

Model 中既包括状态，又包括行为，是最符合面向对象的设计方式。

以下为举例说明：

对于员工Employee来说，每个员工的属性有Id，Name,Sex,BirthDay,Parent（上级），行为有查找，保存，删除，职位调整（更换上级） 等

采用贫血模型实现

Model:

public class EmpService
{
public void Test()
{
Employee emp1 = new Employee() { Id = System.Guid.NewGuid().ToString(), Name = "张三", Sex = "男" };
Employee emp2 = new Employee() { Id = System.Guid.NewGuid().ToString(), Name = "李四", Sex = "男", ParentId = emp1.Id };
//插入员工
emp1.Save();
emp2.Save();

//取员工的上级
var emp2Parent = emp2.Parent;
var emp2Parent_Parent = emp2Parent.Parent;

//删除员工
emp2.Drop();
emp1.Drop();
}
}

View Code
总结：

　　从两者Service层和BLL　层的代码区分来看，两者都是实现了业务功能和延迟加载。

贫血模型优点是系统的层次结构清楚，各层之间单向依赖。缺点是不够面向对象。

充血模型优点是面向对象，Business Logic符合单一职责，不像在贫血模型里面那样包含所有的业务逻辑太过沉重。缺点是比较复杂，对技术要求更高。

对于web开发，个人推荐用贫血模型。其实无论是采用哪种模型，都是可以的，只不过作为我们自己，要真正去理解为什么要这么做，以及怎样去解决问题，而不是学到一知半解，把两种方式混用，分出DAL 层来，却又采用充血模型去操作，然后又去遵循贫血模型的规范，把代码写的乱七八糟，层不是层（吐槽一下，在这样的项目里，让我很难受）。

好的代码，应该是简单的，应该是美的，应该是能解决问题而不是制造问题的，不要为了面向对象而面向对象。

以上都是我的个人理解，有不对的地方，欢迎大家指正。

ps:最近在做项目，发现有人在贫血模型中使用Parent类似的这种类,但是又不能解决延时加载的问题，或者是每次用的时候都要再加载，没有添加Parent的意义，反而导致这些对象不能及时回收，心有所感，所以在这里总结一下，与大家分享。