Yii2架構中，有必要再分離service層嗎？

目前的項目中，service層，就是使用靜態方法調用，方法內再執行個體化ar model

而Yii2自動產生的模板中，是直接在model中使用ar model。

兩者沒有多大的區別，那分離出service層的意義是什嗎？

回複內容：

目前的項目中，service層，就是使用靜態方法調用，方法內再執行個體化ar model

而Yii2自動產生的模板中，是直接在model中使用ar model。

兩者沒有多大的區別，那分離出service層的意義是什嗎？

在簡單的系統裡面，分層是這樣的

controller <-> model <-> storage(sql、nosql、cache)

所有的商務邏輯都在model上

現在討論一個常見的情境，使用者下訂單要買點東西，這個商務邏輯涉及到的model類有User（使用者）、Order（訂單）、Goods（商品）

那麼下訂單這個事情是放到User還是Order上？無論放在User還是Order上，這個商務邏輯都需要多個model類的參與

這種需求在系統裡面越來越多，你就會發現你總有那麼幾個model在不斷的膨脹，這些model之間甚至產生了網狀的相互依賴關係

需求越複雜，你越容易陷入這種混亂的局面

service層的作用就是把這些需要多個model參與的複雜商務邏輯單獨封裝出來，這些model之間不再發生直接的依賴，而是在service層內協同完成邏輯

service層的第一個目的其實就是對model層進行解耦

業界對前面提到的那種不斷膨脹的model稱為“充血模型”，起初對充血模型進行反思的一種解決方案就是“貧血模型”，model裡面盡量少放點邏輯，把這些邏輯都移動到controller層面去處理，在controller裡面調用多個model完成商務邏輯，也達到了對model間解耦的作用

但問題就是，商務邏輯都放到controller層面了，如果其它的controller也需要相同的商務邏輯時，只能在controller裡面調用其它的controller，這樣做既不方便又麻煩

所以後來還是把這種解耦單獨放一層，叫service，現在分層就變成這樣

controller <-> service <-> model <-> storage

service層的第二個作用就是重用

差不多就是這樣

簡單粗暴的總結來說，如果你的某個商務邏輯，需要用到多個model，就放到service層裡面去，如果只是這個model自己的事，跟其它的model沒有任何關係，就放到model裡面就好。

如果你的系統本來就很小，商務邏輯也超級簡單，也不存在長期演化迭代的需求，隨你怎麼高興怎麼寫都行。

取決於model層是否夠亂。

該不該分離出新的層，有無service層都有各自的好處，沒有優劣。

亂了才拆，不亂不管，就看合適不合適。

如果真的很亂，非拆分不可，想必題主也不會再提問，所以推測現在是剛開始亂。

如果真是這樣，其實這就是開始亂了，推薦現在就拆。

分層永遠是處理複雜業務的有效手段（一般項目三層，複雜的項目回到四層、五層）。

在面向OO的系統裡，service就是biz manager，在面向過程的系統裡service就是TS指令碼。

AR Model裡面當然可以放業務代碼，但僅限於操作這個model自身（如果使用了repository則也不能操作同類型別的model，而應該在repository中操作某一類models），不對其他類型model產生依賴。

業務manager（也就是所謂的service）則根據業務，處理不同類型model或者repository之間的關係。

業務更加複雜時可以抽出子系統的facade門面，處理不同業務manager調用順序。

最後在controller裡調用它們（對， controller也可以認為是一個facade）。

我接觸過的項目都在這幾層裡面，再複雜也就到facade。小項目當然直接扔到model裡，，隨著業務不斷複雜，我們要做的只是不斷重構而已。

