8 回答

TA貢獻1876條經驗 獲得超5個贊
我覺得Controller
不負責處理數據是正確的, 因為在spring-mvc
中Controller
是不能復用的, 但是如果你把業務邏輯抽象成Service
, 那么這個Service
就是可以復用的.
至于你說的 "在Controller就將對象封裝好了,就免于在Service的方法中多次封裝" , 沒太明白什么意思, 你每個Service
需要什么參數, Controller
就給什么參數, 至于需要的參數是否需要封裝成對象就可以自己權衡了.
你所說的login(String username,String password)
, 你想抽象成Service
用異常處理處理多種不同的結果, 這個我覺得完全沒有問題, 而且我覺得非常好啊, 很多認證框架都用的這種方式, 至少我看的apache-shiro
就是用異常處理認證失敗的不同情況的.

TA貢獻1817條經驗 獲得超6個贊
第一個問題感覺沒有標準答案,具體情況具體分析,邏輯分層清晰易于維護就好。
第二個問題的話,你這里給出的交互是隸屬于權限控制的,一般用filter、aop、代理、反射等等方式實現代碼收束都可以,異常也在這些集中控制的代碼里扔一次就好,直接在Controller里硬編碼我反倒覺得累贅。Service這一層更多的是調用Dao層的方法來實現一些復雜的涉及多表的業務邏輯處理,事務也放在這一層(當然現在框架把這事兒都干了),所以Service這一層一般不扔異常(參數驗證在Controller以及之前的層次都做掉了因此不出現業務相關異常,而Dao把數據庫相關的底層異常屏蔽了)。
當然這是個人看法,沒有定式,還是那句話,分層清晰易于維護就好。

TA貢獻1869條經驗 獲得超4個贊
1、Controller默認是單例的,但可用@Scope(value = "prototype")替換
2、登錄可以返回int啊,自己加個枚舉
3、規定是在Service層處理邏輯,要看業務的吧,代碼冗余度低些好,也好優化
大家觀點會不同,做開發更多的還是優化改,降低冗余度,而不是必須要怎么做。。。

TA貢獻1807條經驗 獲得超9個贊
1,Controller應盡可能的不設計業務邏輯,只涉及交互
2,Service為可復用的業務邏輯
3,Controller為Service的上級調用方
4,你這個case可以在Service中返回固定的返回值,在Controller層做判斷,并拋出你想相應的異常。
當然了這只是我們目前的做法,分享一下。。。

TA貢獻1844條經驗 獲得超8個贊
封裝對象到底在Controller還是Service,還是要看具體的情況,個人認為如果是簡單的參數在Controller中進行封裝時是完全可以的,如果放到Service反而會顯得很冗余,而且導致Service通用性變差;對于第二個問題,不容同意通過枚舉或者不同的狀態碼來在Controller左做判斷拋出異常,完全可以自己定義一套異常處理機制,直接在Service層拋出,項目有針對此類業務異常的處理機制,直接兩將Service的錯誤信息和錯誤碼返回到View層,讓客戶端根據狀態碼和錯誤信息作處理
添加回答
舉報