TA貢獻2019條經驗 獲得超9個贊
取決于model層是否夠亂。
該不該分離出新的層，有無service層都有各自的好處，沒有優劣。
亂了才拆，不亂不管，就看合適不合適。
如果真的很亂，非拆分不可，想必題主也不會再提問，所以推測現在是剛開始亂。
如果真是這樣，其實這就是開始亂了，推薦現在就拆。
TA貢獻1851條經驗 獲得超5個贊
在簡單的系統里面，分層是這樣的
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里面就好。
如果你的系統本來就很小，業務邏輯也超級簡單，也不存在長期演進迭代的需求，隨你怎么高興怎么寫都行。
舉報