在不分層的系統(tǒng)里,我們可以將所有的代碼都寫到一個(gè)地方,比如struts的Action類。在這里,我們不僅要處理頁面邏輯,還要做業(yè)務(wù)邏輯,還要做數(shù)據(jù)訪問。比如說:
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;
}
|
那么上面的代碼,哪些部分是頁面的部分,哪些是業(yè)務(wù)處理,哪些是數(shù)據(jù)訪問呢?我認(rèn)為,這個(gè)劃分方法是:Action里只做和頁面相關(guān)的事,不操作業(yè)務(wù)對(duì)象;Service不依賴于任何表現(xiàn)技術(shù),不操縱任務(wù)用于表現(xiàn)的對(duì)象,對(duì)于業(yè)務(wù)對(duì)象,尤其是跨多個(gè)業(yè)務(wù)對(duì)象的操作,要放到Service里面來;最后,單純的業(yè)務(wù)對(duì)象的存取,組裝放到DAO里完成。上面所說的業(yè)務(wù)對(duì)象,就是像上例中role, result等和業(yè)務(wù)相關(guān)的對(duì)象,而SUCCESS, inputID等,則是頁面相關(guān)的部分。因些,可以將上例改為:
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();
}
|
這樣分層,看起來會(huì)顯得很麻煩,但事實(shí)上確實(shí)是大有好處,首先:
代碼更易讀。每一層的每個(gè)方法的意義和目的更加明確,讀以起來受的干擾更少。
拆開后的每一層都更容易測試。
具體如何分層,還需要在開發(fā)中,多多體會(huì),這沒有絕對(duì)的界限,也許一開始放在action里的頁面的控制后來會(huì)上升為業(yè)務(wù)規(guī)則,并被其它地方重用,然后被移入service;也許某一塊對(duì)數(shù)據(jù)的存取也變得非常復(fù)雜,包含了業(yè)務(wù)邏輯,然后被移入service;也有可能發(fā)現(xiàn)以前寫的service根本沒有想像的那樣的業(yè)務(wù)邏輯,只是幫助做了一些頁面的流程控制,然后被重構(gòu)成Action的一個(gè)方法,等等。
posted on 2009-05-14 18:13
Werther 閱讀(5804)
評(píng)論(8) 編輯 收藏