在不分层的系统里，我们可以将所有的代码都写到一个地方，比如struts的Action类。在这里，我们不仅要处理页面逻辑，还要做业务逻辑，还要做数据访问。比如说：
public String addUser() {
if(user == null) {
return FAIL_NO_USER;
}
Result result = null;
if(Role.ADMIN.equals(user.getRole())) {
result = doSomethingForAdmin(user) ;
} else {
result = doSomethingForOthers(user);
}
Transaction trans = sess.beginTransaction();
Query query = sess.createQuery("update Result set level = :level");
query.setParameter("level", result.getLevel());
query.executeUpdate();
trans.commit();
sess.close();
return SUCCESS;
}
if(user == null) {
return FAIL_NO_USER;
}
Result result = null;
if(Role.ADMIN.equals(user.getRole())) {
result = doSomethingForAdmin(user) ;
} else {
result = doSomethingForOthers(user);
}
Transaction trans = sess.beginTransaction();
Query query = sess.createQuery("update Result set level = :level");
query.setParameter("level", result.getLevel());
query.executeUpdate();
trans.commit();
sess.close();
return SUCCESS;
}
那么上面的代码，哪些部分是页面的部分，哪些是业务处理，哪些是数据访问呢？我认为，这个划分方法是：Action里只做和页面相关的事，不操作业务对象；Service不依赖于任何表现技术，不操纵任务用于表现的对象，对于业务对象，尤其是跨多个业务对象的操作，要放到Service里面来；最后，单纯的业务对象的存取，组装放到DAO里完成。上面所说的业务对象，就是像上例中role, result等和业务相关的对象，而SUCCESS, inputID等，则是页面相关的部分。因些，可以将上例改为：
public String addUser() {
if(user == null) {
return FAIL_NO_USER;
}
Result result = service.process(user);
dao.update(result);
return SUCCESS;
}
if(user == null) {
return FAIL_NO_USER;
}
Result result = service.process(user);
dao.update(result);
return SUCCESS;
}
在service里:
public Result process(User user) {
Result result = null;
if(Role.ADMIN.equals(user.getRole())) {
result = doSomethingForAdmin(user) ;
} else {
result = doSomethingForOthers(user);
}
return result;
}
Result result = null;
if(Role.ADMIN.equals(user.getRole())) {
result = doSomethingForAdmin(user) ;
} else {
result = doSomethingForOthers(user);
}
return result;
}
在dao里：
public void update(Result result) {
Transaction trans = sess.beginTransaction();
Query query = sess.createQuery("update Result set level = :level");
query.setParameter("level", result.getLevel());
query.executeUpdate();
trans.commit();
sess.close();
}
Transaction trans = sess.beginTransaction();
Query query = sess.createQuery("update Result set level = :level");
query.setParameter("level", result.getLevel());
query.executeUpdate();
trans.commit();
sess.close();
}
这样分层，看起来会显得很麻烦，但事实上确实是大有好处，首先：
- 代码更易读。每一层的每个方法的意义和目的更加明确，读以起来受的干扰更少。
- 拆开后的每一层都更容易测试。
具体如何分层，还需要在开发中，多多体会，这没有绝对的界限，也许一开始放在action里的页面的控制后来会上升为业务规则，并被其它地方重用，然后被移入service；也许某一块对数据的存取也变得非常复杂，包含了业务逻辑，然后被移入service；也有可能发现以前写的service根本没有想像的那样的业务逻辑，只是帮助做了一些页面的流程控制，然后被重构成Action的一个方法，等等。
是这样的，比较通用的分层:jsp->action->service->dao->db，只是有时service里的逻辑完全可以在action里做掉，service被弱化了。
尤其现在使用OR映射框架后，已经把dao变的很清晰和松散了，action里直接跟dao打交道也并不难看，所以service真的有点没那么必要了。
各层的界限确实难以划分，但是只是细心去发现，还是可以分开的。而且分层确有必要，至少现在我们不能对java方法中一个代码段做测试，最小的测试单元也是方法。为了测试的需要，分开是值得的。
另一方面，人家看到service.doSomething() dao.findSomethingBy()时，意义也更加明确，比放到一起易读性要好。
你觉得呢？
没错，层次分的清晰，测试是最大的受益。
一堆代码可以说明什么呢.
不错。分层好，代码清晰，容易测试。
不分层也好。开发快速。
朝哪个方向呢？还是采用重构？
写的很好，对action的认识清楚了。
还有点不明白的，
在dao里只是包括对单个对象的增删查改？而在service层调用不同的DAO来进行操作吗？
可以呀，没什么问题。