数据库中的表对应生成实体类 只有属性 没有行为 -- 贫血模型 贴子
一个项目设计的好坏，是否不应该单纯看其设计思路是否符合OO原则，而应该考虑这个设计给项目带来的整体实施成本。
相比之下，失血模型和贫血模型的domain ojbect层非常稳定(基本可以使用工具生成了)，而且编写相对很简单，复杂的业务逻辑交给Service去实现，大家分工明确，不同编码水平的coder可以很好的配合起来，完成项目的高质量实现。而胀血模型中,对domain ojbect的编写显得非常重要,因为domain ojbect本身就包含了事务封装和业务逻辑。
另外大胆说一句，是否OO有时并不取决于我们的设计，而是要受技术条件的限制的。假设数据库本身可以提供的不是关系型数据而是对象集，假如我们不需要DAO编码，设计本身，会更加漂亮。
从语义的角度,domain object不能仅仅包括对业务对象的静态描述,还应该包括业务对象的行为描述,但是实际操作中,这种模型很难得到较好的实现.所以我的核心体会就是:应该选择最适合这个项目的设计模型,而不是理论上最"美"的模型.
贫血模型理论上的主要缺陷：
1:Item和ItemManager实际是操作与数据的关系,实际完成的就是经典OO中的一个对象的能力;
2:当有许多Item时 类组变得很庞大,产生很多 xxxDao xxxImpl xxxManager 其中包含大量重复代码;
按<<重构>>的观点,上述代码存在以下臭味:
1:重复的代码 xxxDao xxxImpl xxxManager(通常)
2:霰弹式修改，一个变化影响多个类,类之间不够高内聚 item变化-->Dao,Impl,Manager均要变动
3:依恋情结,两个类之间互相作用过多 item<->Manager
4:平行继承体系,当增加一个新类时总是要增加另一个类
5:夸夸其谈未来性,在没有任何暗示的情况下考虑扩展 Dao,实际HibernateImpl可能n年内是唯一的Dao实现
6:纯稚的数据类，只有数据的类 item
转载自http://joey.cnblogs.com/archive/2006/04/07/369022.html
相比之下，失血模型和贫血模型的domain ojbect层非常稳定(基本可以使用工具生成了)，而且编写相对很简单，复杂的业务逻辑交给Service去实现，大家分工明确，不同编码水平的coder可以很好的配合起来，完成项目的高质量实现。而胀血模型中,对domain ojbect的编写显得非常重要,因为domain ojbect本身就包含了事务封装和业务逻辑。
另外大胆说一句，是否OO有时并不取决于我们的设计，而是要受技术条件的限制的。假设数据库本身可以提供的不是关系型数据而是对象集，假如我们不需要DAO编码，设计本身，会更加漂亮。
从语义的角度,domain object不能仅仅包括对业务对象的静态描述,还应该包括业务对象的行为描述,但是实际操作中,这种模型很难得到较好的实现.所以我的核心体会就是:应该选择最适合这个项目的设计模型,而不是理论上最"美"的模型.
贫血模型理论上的主要缺陷：
1:Item和ItemManager实际是操作与数据的关系,实际完成的就是经典OO中的一个对象的能力;
2:当有许多Item时 类组变得很庞大,产生很多 xxxDao xxxImpl xxxManager 其中包含大量重复代码;
按<<重构>>的观点,上述代码存在以下臭味:
1:重复的代码 xxxDao xxxImpl xxxManager(通常)
2:霰弹式修改，一个变化影响多个类,类之间不够高内聚 item变化-->Dao,Impl,Manager均要变动
3:依恋情结,两个类之间互相作用过多 item<->Manager
4:平行继承体系,当增加一个新类时总是要增加另一个类
5:夸夸其谈未来性,在没有任何暗示的情况下考虑扩展 Dao,实际HibernateImpl可能n年内是唯一的Dao实现
6:纯稚的数据类，只有数据的类 item
转载自http://joey.cnblogs.com/archive/2006/04/07/369022.html
