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; 　　}

　　那么上面的代碼，哪些部分是頁面的部分，哪些是業務處理，哪些是數據訪問呢?我認為，這個劃分方法是：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; 　　} 　　在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的一個方法，等等。