在不分层的系统里,我们可以将所有的代码都写到一个地方,比如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; } |
public String addUser() { 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; } 在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(); } |
代码更易读。每一层的每个方法的意义和目的更加明确,读以起来受的干扰更少。
拆开后的每一层都更容易测试。
具体如何分层,还需要在开发中,多多体会,这没有绝对的界限,也许一开始放在action里的页面的控制后来会上升为业务规则,并被其它地方重用,然后被移入service;也许某一块对数据的存取也变得非常复杂,包含了业务逻辑,然后被移入service;也有可能发现以前写的service根本没有想像的那样的业务逻辑,只是帮助做了一些页面的流程控制,然后被重构成Action的一个方法,等等。