2006年12月2日

我们现在通常用的开发层次都是 页面-〉Action -〉Serice -〉Dao -〉DB
Service中进行业务处理
Dao中进行和数据库相关的一些CUID处理

下面就出现了一个比较困扰我的问题 比如一个简单的例子，我要取一个员工Employee
的信息到页面，我要调用 通过Action 调用 Service的 loadEmployee(...) 的方法
然后在 Dao 中调用 loadEmployee(...) 方法 , 我的困惑就是Entity和VO 到底各自
负责什么事情。

我考虑了3种情况：
1、load方法中的参数是比如这样的 (String employee, int age ... )
 Service中 返回的是 VO 到页面
 Dao中 返回 Entity
 
 Serivce中的方法大概这样写
 
 public EmployeeBean loadEmployeeBean(String employee, int age ... ) {
  EmployeeEntity employeeEntity = employeeDao.loadEmeployee(String employee,

int age ... );
  ... 属性Copy ...
  return employeeBean;
 }

2、load方法中的VO是比如这样的 Service 中参数是 (EmployeeBean employeeBean) Dao中的参数是
(EmployeeEntity employeeEntity)
 其他同方法1

3、第三种方法的参数传递方式和第二种一样但是 Dao 返回的不是一个Entity 而是一个VO
 public EmployeeBean loadEmployeeBean(EmployeeBean employeeBean) {
  EmployeeBean employeeBean = employeeDao.loadEmeployee(EmployeeBean

employeeBean);
  ... 逻辑操作 ...
  return employeeBean;
 }

第一种情况参数固定很难扩展
第二种情况Dao 返回Entity 把Entity 暴露在 Service 下 并且要繁琐的 properties Copy 操作
觉得很不爽 有人会说用BeanUtils 但是如果属性类型不一样的话很麻烦 多表操作更麻烦

我把第三种情况在详细的描述一下
其实这几种情况的主要差别就是 参数 和 返回值
第三种情况中  Service  和 Dao 中传入的 参数 和 返回值 都是 VO 对象
参数是VO的好处就是 可以 在不用改变方法的情况下 增加 查询条件 当然减少也可以
返回对象是VO的好处就是 多表查询 返回 某些字段 可以封装在VO对象中 这样取值比较方便

我个人比较倾向于 第三种情况
不知道各位有何高见