剛進公司,參加了兩個項目一個是日本外包,一個是自己的產品。這個兩個系統在設計上都有一個要求,就是業務邏輯要放到Service層來完成,Action中盡量少寫東西。這一點可以理解,但是存在這樣一個問題,在service中進行業務邏輯處理時免不了要發生問題,要把這些問題顯示在頁面上,但是service層不能直接接觸到action,所以著這兩個項目中的設計方法上使吧actionmessages對象給了service。我認為這樣做很不好,這樣service對表現曾的依賴就太大了,因為ActionMessages是Struts的東西,也就是說這個serivce只能用來對Struts提供服務了。我認為應該在service曾定義好異常情況,遇到問題時拋出異常(RuntimeException),然后再表現層根據異常種類做出相應的動作。這樣就是view層依賴于serivce層,而service層可以為更多種view層提供服務了。但是這樣也有一些問題,就是如果serivce邏輯復雜,可能異常種類就非常多,這樣項目做起來也很麻煩。 但是剛進公司也沒有什么發言權,估計前輩們也知道這樣做不好,但是估計是為了項目做起來不會太麻煩吧。
大家有沒有更好的辦法?
大家有沒有更好的辦法?
Actions 負責撲捉異常
這樣可以吧?
定義自己的應用異常,
異常里面可以自定義錯誤編號,錯誤信息等錯誤信息,actions可以統一處理。
我一般都是
throws new ServeciException("error.username.isexist",e);
當然,每個層最好還是定義個異常類。
1.這樣和error code 的形式想比會使這種business exception顯示的表示, 會有type check之類的益處, 同時異常的名字會很清晰的表明它的業務意義.
2.會強迫controller層對這個異常進行處理(或者繼續向上拋)
盡管有這些益處,但缺點也有:
1.有時會造成business exception過多的情況, 業務方法的throws 語句會很長,使得業務方法看起來很Ugly.
2.因為是checked exception,一旦service 層的業務方法增加一個異常,將使得controller受到影響, 這種影響會從service層向外傳播.
針對缺點 1, 應該謹慎設計一些業務方法, 如果發現拋出的business exceptin過長, 問問自己是不是這個方法承擔的責任太多, 或者一些business exception可以合并為一個有意義的異常.
針對缺點 2, 沒有辦法,這是checked exception的特點, 任何事物都是兩面性.
一般的business exception都會在controller層try/catch,返回相應的信息到客戶端, 目的是告訴客戶問題出在哪里,讓他們恢復.所以我們可以認為這些異常是可恢復的異常,這是business exception作為checked exception的一個理由.