一、失血模型
只有getter和setter方法的实体类,所有的业务逻辑完全由Service层来完成。
代码示例:
Domain:
DAO接口:
DAO实现:
Service层:
二、贫血模型
领域对象包含不依赖于持久化的领域逻辑,而那些依赖持久化的领域逻辑被分离到Service层。
示例代码:
Domain:
Service层:
三、充血模型
绝大部分业务逻辑被放在领域对象中(包括持久化逻辑),而Service层仅仅封装事务和少量逻辑,不调用DAO层。
示例代码:
Domain:
Service层:
四、胀血模型
去掉Service层,只保留领域对象。
示例代码:
Domain:
[quote]
失血模型和胀血模型是不被提倡的,推荐使用贫血模型。
失血模型缺点:
无任何业务逻辑的纯实体类
胀血模型缺点:
1、很多不是领域对象的业务逻辑也被强行放入领域对象,导致领域对象不稳定
2、暴露给web层过多的领域对象信息
充血模型缺点:
考虑到Service层的事务封装特性,Service层必须对所有领域对象的逻辑提供相应的事务封装方法,其结果就是Service层完全重定义一遍所有的领域对象。而且Service层的事务化封装其意义就等于把OO的领域对象转换为过程的Service TransactionScript。该充血模型在Domain层实现的OO在Service层又变成了过程式,从Web层程序员的角度来看,和贫血模型没有区别
贫血模型优点:
1、各层单向依赖,结构清楚,易于实现和维护
2、设计简单易行,底层模型非常稳定
[/quote]
只有getter和setter方法的实体类,所有的业务逻辑完全由Service层来完成。
代码示例:
Domain:
public class Person {
private long id;
private String name;
private int age;
//getter and setter …
}
DAO接口:
public interface PersonDAO {
public Person findPersonById(long id);
}
DAO实现:
public class IbatisPersonDAO implements PersonDAO {
private SqlMapClientTemplate sqlMapClientTemplate = new SqlMapClientTemplate();
public Person findPersonById(long id) {
return (Person) sqlMapClientTemplate.queryForObject("MS-PERSON-FIND-PERSON-BY-ID", id);
}
}
Service层:
public class PersonService {
private IbatisPersonDAO ibatisPersonDAO;
public Person findPersonInfo(long id) {
return ibatisPersonDAO.findPersonById(id);
}
public void setIbatisPersonDAO(IbatisPersonDAO ibatisPersonDAO) {
this.ibatisPersonDAO = ibatisPersonDAO;
}
}
二、贫血模型
领域对象包含不依赖于持久化的领域逻辑,而那些依赖持久化的领域逻辑被分离到Service层。
示例代码:
Domain:
public class Person {
private long id;
private String name;
private int age;
public void modifyPerson(long id, String name, int age) {
this.id = id;
this.name = name;
this.age = age;
}
//getter and setter ...
}
Service层:
public class PersonService {
private IbatisPersonDAO ibatisPersonDAO;
public void modifyPersonInfo(long id,String name,int age) {
Person person = new Person();
person. modifyPerson(id,name,age);
ibatisPersonDAO.updatePersonById(person);
}
public void setIbatisPersonDAO(IbatisPersonDAO ibatisPersonDAO) {
this.ibatisPersonDAO = ibatisPersonDAO;
}
}
三、充血模型
绝大部分业务逻辑被放在领域对象中(包括持久化逻辑),而Service层仅仅封装事务和少量逻辑,不调用DAO层。
示例代码:
Domain:
public class Person {
private long id;
private String name;
private int age;
private IbatisPersonDAO ibatisPersonDAO;
public void modifyPerson(long id,String name,int age) {
this.id = id;
this.name = name;
this.age = age;
ibatisPersonDAO.updatePersonById(this);
}
//getter and setter ...
}
Service层:
public class PersonService {
public void modifyPersonInfo(long id, String name, int age) {
Person person = new Person();
person.modifyPerson(id,name,age);
}
}
四、胀血模型
去掉Service层,只保留领域对象。
示例代码:
Domain:
public class Person {
private long id;
private String name;
private int age;
private IbatisPersonDAO ibatisPersonDAO;
public void modifyPerson(long id, String name, int age) {
this.id = id;
this.name = name;
this.age = age;
ibatisPersonDAO.updatePersonById(this);
}
//getter and setter ...
}
[quote]
失血模型和胀血模型是不被提倡的,推荐使用贫血模型。
失血模型缺点:
无任何业务逻辑的纯实体类
胀血模型缺点:
1、很多不是领域对象的业务逻辑也被强行放入领域对象,导致领域对象不稳定
2、暴露给web层过多的领域对象信息
充血模型缺点:
考虑到Service层的事务封装特性,Service层必须对所有领域对象的逻辑提供相应的事务封装方法,其结果就是Service层完全重定义一遍所有的领域对象。而且Service层的事务化封装其意义就等于把OO的领域对象转换为过程的Service TransactionScript。该充血模型在Domain层实现的OO在Service层又变成了过程式,从Web层程序员的角度来看,和贫血模型没有区别
贫血模型优点:
1、各层单向依赖,结构清楚,易于实现和维护
2、设计简单易行,底层模型非常稳定
[/quote]