首頁猿問在MVC開發(fā)模式中，封裝對象應(yīng)該放...

在MVC開發(fā)模式中，封裝對象應(yīng)該放在Controller還是Service？Controller與Service應(yīng)該如何交互？

Java

哆啦的時(shí)光機(jī) 2019-03-01 11:02:57

已經(jīng)學(xué)了兩年的MVC了，但是有些概念還是很模糊，希望能在這里尋找到答案。我曾經(jīng)看到有人說Controller不負(fù)責(zé)數(shù)據(jù)處理，全部交給我們的Service來處理，網(wǎng)頁前端傳回來是什么數(shù)據(jù)類型，就直接把數(shù)據(jù)類型轉(zhuǎn)發(fā)到Service，然后由Service來處理；但是又有另外一種聲音說有時(shí)候會(huì)同時(shí)調(diào)用多個(gè)Service，如果在Controller就將對象封裝好了，就免于在Service的方法中多次封裝。另外還有一個(gè)問題就是關(guān)于Controller與Service的交互問題。我們?yōu)榱饲岸说目蛻艚换チ己?，往往?huì)通過Controller向前端返回一些錯(cuò)誤提示，比如用戶名已存在，用戶名和密碼不匹配等等。可是處理業(yè)務(wù)邏輯我們是放在Service層，那么如果把一個(gè)login(String username,String password)方法的返回值設(shè)定為boolean就無法返回多種錯(cuò)誤，但是如果返回String類型，就需要設(shè)定一些基本的字典。我自己“奇思妙想”，我在Service中通過拋出我自定義的一些RuntimeException，然后在Controller中通過TryCatch來處理不同的錯(cuò)誤，但是我自己認(rèn)為這種拋出異常的方式不妥。最近就陷入了迷茫，馬上就要開始做下一個(gè)項(xiàng)目了。希望各位能幫我解答一下迷惑。感謝。

查看完整描述

8 回答

慕運(yùn)維8079593

TA貢獻(xiàn)1876條經(jīng)驗(yàn) 獲得超5個(gè)贊

我覺得Controller不負(fù)責(zé)處理數(shù)據(jù)是正確的, 因?yàn)樵?code>spring-mvc中Controller是不能復(fù)用的, 但是如果你把業(yè)務(wù)邏輯抽象成Service, 那么這個(gè)Service就是可以復(fù)用的.

至于你說的 "在Controller就將對象封裝好了，就免于在Service的方法中多次封裝" , 沒太明白什么意思, 你每個(gè)Service需要什么參數(shù), Controller就給什么參數(shù), 至于需要的參數(shù)是否需要封裝成對象就可以自己權(quán)衡了.

你所說的login(String username,String password), 你想抽象成Service用異常處理處理多種不同的結(jié)果, 這個(gè)我覺得完全沒有問題, 而且我覺得非常好啊, 很多認(rèn)證框架都用的這種方式, 至少我看的apache-shiro就是用異常處理認(rèn)證失敗的不同情況的.

反對回復(fù) 2019-03-01

慕的地6264312

TA貢獻(xiàn)1817條經(jīng)驗(yàn) 獲得超6個(gè)贊

第一個(gè)問題感覺沒有標(biāo)準(zhǔn)答案，具體情況具體分析，邏輯分層清晰易于維護(hù)就好。

第二個(gè)問題的話，你這里給出的交互是隸屬于權(quán)限控制的，一般用filter、aop、代理、反射等等方式實(shí)現(xiàn)代碼收束都可以，異常也在這些集中控制的代碼里扔一次就好，直接在Controller里硬編碼我反倒覺得累贅。Service這一層更多的是調(diào)用Dao層的方法來實(shí)現(xiàn)一些復(fù)雜的涉及多表的業(yè)務(wù)邏輯處理，事務(wù)也放在這一層（當(dāng)然現(xiàn)在框架把這事兒都干了），所以Service這一層一般不扔異常（參數(shù)驗(yàn)證在Controller以及之前的層次都做掉了因此不出現(xiàn)業(yè)務(wù)相關(guān)異常，而Dao把數(shù)據(jù)庫相關(guān)的底層異常屏蔽了）。

當(dāng)然這是個(gè)人看法，沒有定式，還是那句話，分層清晰易于維護(hù)就好。

反對回復(fù) 2019-03-01

MMTTMM

TA貢獻(xiàn)1869條經(jīng)驗(yàn) 獲得超4個(gè)贊

1、Controller默認(rèn)是單例的，但可用@Scope(value = "prototype")替換

2、登錄可以返回int啊，自己加個(gè)枚舉

3、規(guī)定是在Service層處理邏輯，要看業(yè)務(wù)的吧，代碼冗余度低些好，也好優(yōu)化

大家觀點(diǎn)會(huì)不同，做開發(fā)更多的還是優(yōu)化改，降低冗余度，而不是必須要怎么做。。。

反對回復(fù) 2019-03-01

函數(shù)式編程

TA貢獻(xiàn)1807條經(jīng)驗(yàn) 獲得超9個(gè)贊

1，Controller應(yīng)盡可能的不設(shè)計(jì)業(yè)務(wù)邏輯，只涉及交互
2，Service為可復(fù)用的業(yè)務(wù)邏輯
3，Controller為Service的上級(jí)調(diào)用方
4，你這個(gè)case可以在Service中返回固定的返回值，在Controller層做判斷，并拋出你想相應(yīng)的異常。

當(dāng)然了這只是我們目前的做法，分享一下。。。

反對回復(fù) 2019-03-01

婷婷同學(xué)_

TA貢獻(xiàn)1844條經(jīng)驗(yàn) 獲得超8個(gè)贊

封裝對象到底在Controller還是Service，還是要看具體的情況，個(gè)人認(rèn)為如果是簡單的參數(shù)在Controller中進(jìn)行封裝時(shí)是完全可以的，如果放到Service反而會(huì)顯得很冗余，而且導(dǎo)致Service通用性變差；對于第二個(gè)問題，不容同意通過枚舉或者不同的狀態(tài)碼來在Controller左做判斷拋出異常，完全可以自己定義一套異常處理機(jī)制，直接在Service層拋出，項(xiàng)目有針對此類業(yè)務(wù)異常的處理機(jī)制，直接兩將Service的錯(cuò)誤信息和錯(cuò)誤碼返回到View層，讓客戶端根據(jù)狀態(tài)碼和錯(cuò)誤信息作處理

反對回復(fù) 2019-03-01