通常我們在做一套系統時，一個請求的流程大概是action（controller）->service->dao，這個流程很清晰，也很簡單，但是在具體業務中我們可能需要不同的業務之間的配合使用，這時可能需要service中調用service。例如AService中調用BService,BService中又調用CService，CService又調用AService，這樣我們就造成了A中注入B，B中注入C，C中又注入A的循環注入情況，這時Spring在初始化時就出問題了。在查詢了一些資料中，基本上意見都是“這屬于系統設計問題”，經過不斷的思考，我想出一個解決辦法，那就是我們在普通的三層設計中再添加一層（BusinessService），我們規定：1，**Service層只面向單表（這里的單表指的是不注入其他service層，當然在寫sql時仍然可以join其他表，不過返回結果就需要自定義一個dto來接收）**。2，**若在service層只對數據庫負責，要進行數據持久時，不校驗數據的正確性，只校驗數據是否為空，是否符合數據庫的非空約束、是否符合數據庫的索引約束等。**若有比較復雜的業務（需要多個子業務支撐）時，我們在Business層中統一調用多個service層的方法，然后依次由BusinessService層進行組裝和事務控制，舉個例子：我們現在有一個添加學生個業務，添加學生總共有3個子業務 1，保存學生基本信息 2，更新學生所在的班級學生數量 3，更新學生所在的學校的學生總數那我們只需要在StudentBusinessService中依次注入StudentService、ClassStudentCountService、SchoolStudentCountService，并在StudentBusinessService中的add方法內依次調用這三個子業務的對應方法即可。如此，這樣A->B-C->A 就變成了 A-B,A-C（A層為BusinessService層，B、C為service層，service層永遠不會調用BusinessService層，從而打破了之前循環結構） 從而解決了之前的問題了但是，隨著業務的增長，之前在BusinessService中定義的方法可能成為更大的一個業務中的一個子業務了，舉個例子，教師在從一個校區調到另一個校區，此時需要將該教師原有的學生全部加入到現在的校區中（**此處為業務規定，不做合理性解釋**）那么也很簡單，我們需要在TeacherBusinessService中注入StudentBusinessService即可，然后調用StudentBusinessService的add方法，然后add方法會調用其他子業務，但是這樣可能又回到了之前的A->B-C-A的模式了，隨著業務的增長，很可能又會出現循環注入的問題。我暫時還沒想出更好的解決辦法，不知各位是如何處理類似的問題的？
4 回答
慕姐8265434
TA貢獻1813條經驗 獲得超2個贊
我覺得這確實是系統設計問題，一般系統分層原則是，越是底層越細化，例如數據庫的DAO基本是針對單個表的，越往上層越抽象化，比如某個Service可能會注入多個DAO來實現某個業務。
你提的問題應該就是Service沒有按照職責劃分清楚，比如StudentService應只能實現Student相關的業務，其它的業務應該不歸它管理，因此在StudentService里面不應該調用ClassService或者SchoolService。
就如你所言的解決方案，Service層本身根據不同的業務職責是可以分成多個層，只要確保在同一層里面的Service不會互相引用（也不應該引用），復雜的業務需求應當由更上層的Service提供。
三層設計只是一個指導方針，你可以擴展成n層，這依賴你業務需求的復雜度。
MMTTMM
TA貢獻1869條經驗 獲得超4個贊
首先，對于Spring中的循環引用是不會有問題的，而且循環引用在很多時候也是不可避免，很多設計模式實際上都存在著循環引用的情況。
其次，對于像StudentService只調用StudentDao的情況只是理想情況下出現的，實際場景下，一個Service肯定會調用其他Service來完成自身功能。若不希望存在循環引用的情況，那只能讓Service依賴Dao（因為Dao之間是不會存在互相依賴的情況），但這樣做會造成大量的代碼冗余，粒度也過細。
最后，在業務實現中，循環引用是正常的，對于Spring的管理、事物的處理來說都不會產生問題。
添加回答
舉報
0/150
提交
取消