新接手的代码，发现在Controller里处理的逻辑就有几百行代码?又没有事务管理，这么做好吗?
欢迎选择我的课程，让我们一起见证您的进步~~
標準的MVC確實是直接在controller中實現業務邏輯，但實際專案裡，還是會建議在controller和資料庫操作之間封裝服務層。 一方面，controller在對應不同的請求url，從功能上會存在很多重複；不好維護；另一方面，要考慮你的服務功能將來可能暴露給其他前端，比如其他應用接入，或者不同的終端（如APP、行動H5等）；有些服務甚至可能單獨剝離出來獨立部署；
很不好，擴充起來很費勁，維護性也很差。
controller應該是薄薄的一層，業務邏輯盡量後置在服務層去處理，在服務粒度、服務利用上也更加自由。
當然不好啦，controller層只負責業務資料交互，業務邏輯都交給service層處理
現在我接手的專案Controller層也是奇大無比，一個方法上百行，裡面有多層if嵌套，感覺這樣最大的問題就是在後期維護時會很麻煩，需要理解之前的業務邏輯才能更改；個人感覺較好的方法是controller-service-dao，由service負責具體的邏輯操作，3者之間依次調用，彼此之間盡可能解耦；代碼要盡可能可擴展。
雷雷
即使放到service 還是會一坨。 。還是需要其他的方法來規避 業務複雜的情況，程式碼可維護性差
今天讓同事看代碼.同事第一句話就是,你應該把controller這段代碼放在service中;=_=;主要看業務複雜度吧,如果很簡單的一句業務那沒有從controller到service ,再到dao;也要看整個團隊的開發規範是如何;
標準的MVC確實是直接在controller中實現業務邏輯，但實際專案裡，還是會建議在controller和資料庫操作之間封裝服務層。
一方面，controller在對應不同的請求url，從功能上會存在很多重複；不好維護；
另一方面，要考慮你的服務功能將來可能暴露給其他前端，比如其他應用接入，或者不同的終端（如APP、行動H5等）；有些服務甚至可能單獨剝離出來獨立部署；
很不好，擴充起來很費勁，維護性也很差。
controller應該是薄薄的一層，業務邏輯盡量後置在服務層去處理，在服務粒度、服務利用上也更加自由。
當然不好啦，controller層只負責業務資料交互，業務邏輯都交給service層處理
現在我接手的專案Controller層也是奇大無比，一個方法上百行，裡面有多層if嵌套，感覺這樣最大的問題就是在後期維護時會很麻煩，需要理解之前的業務邏輯才能更改；個人感覺較好的方法是controller-service-dao，由service負責具體的邏輯操作，3者之間依次調用，彼此之間盡可能解耦；代碼要盡可能可擴展。
雷雷
即使放到service 還是會一坨。 。還是需要其他的方法來規避 業務複雜的情況，程式碼可維護性差
今天讓同事看代碼.同事第一句話就是,你應該把controller這段代碼放在service中;=_=;
主要看業務複雜度吧,如果很簡單的一句業務那沒有從controller到service ,再到dao;也要看整個團隊的開發規範是如何;