商務邏輯放在controller層好還是model層好

一直覺得model層只用來操作資料,很多業務的處理放在controller,有種說法叫商務邏輯更適合放在model層,不知道哪種處理更好!
看了tp5.0,好像把商務邏輯放在了model,然後看了一些貼,好多說商務邏輯放在model更好.
連結:https://ruby-china.org/topics/19292

商務邏輯放在model有個問題:好多時候一個商務邏輯需要多個model的配合或者說調用,像CI,model與model之間的互相調用就比較困難,還有model調用model總覺得不好!

看了這個回答:
放在model層，如果需要多個model，則在controller調用，model的介面粒度做好就行了，controller只是負責調用幾個model通訊而已.

覺得商務邏輯放在model比較好:controller來處理接受參數,傳遞參數,包括從前端取,給前端,也包括從model取傳回值,給model參數,這樣controller很清楚的做一件事情(取,給,差不多就是路由,邏輯交個model).

感謝很多人的回答,對mvc有了更深的認識!

回複內容：

一直覺得model層只用來操作資料,很多業務的處理放在controller,有種說法叫商務邏輯更適合放在model層,不知道哪種處理更好!
看了tp5.0,好像把商務邏輯放在了model,然後看了一些貼,好多說商務邏輯放在model更好.
連結:https://ruby-china.org/topics/19292

商務邏輯放在model有個問題:好多時候一個商務邏輯需要多個model的配合或者說調用,像CI,model與model之間的互相調用就比較困難,還有model調用model總覺得不好!

看了這個回答:
放在model層，如果需要多個model，則在controller調用，model的介面粒度做好就行了，controller只是負責調用幾個model通訊而已.

覺得商務邏輯放在model比較好:controller來處理接受參數,傳遞參數,包括從前端取,給前端,也包括從model取傳回值,給model參數,這樣controller很清楚的做一件事情(取,給,差不多就是路由,邏輯交個model).

感謝很多人的回答,對mvc有了更深的認識!

放在model層，如果需要多個model，則在controller調用，model的介面粒度做好就行了，controller只是負責調用幾個model通訊而已

我是放在Repositories，Model只做ORM關聯以及sql查詢之類的。
Controller 只處理請求(請求的資料做校正)和跳轉。
架構是Laravel（看到tp好多都是寫在c層）。

怎麼分都能說出理由，但 MVC 作為一個久經考驗的架構模式，其不同組件的職責是有相當明確的標準的，不妨參考一些架構模式相關的書籍中對 MVC 的描述，看看他們當初劃分職責時是有著什麼樣的考量：

後文內容節選、翻譯自《PATTERN-ORIENTED SOFTWARE ARCHITECTURE》

模式簡介

MVC 模式把一個互動式程式分成了三個組件。 Model 包含了核心的功能和資料。 View 顯示資訊給使用者。 Controller 處理使用者的輸入。 所有的 View 和 Controller 協作構成了使用者介面。另有一個“變動通知機制”（意譯，後文提到實現時可用訂閱模式即觀察者模式）來確保 UI 和 model 之間的一致性。

適合應用該模式的環境：

有著靈活多變的人機互動介面的互動式程式。

解決的問題

總結如下幾點：

1. 使用者介面通常非常容易變動（新功能、客戶改需求等等）

2. 介面經常會需要為同一個功能提供多種不同的使用方式（滑鼠右鍵、功能表列、快速鍵、浮窗）

3. 介面和功能結合緊密的程式維護起來通常非常昂貴困難，且很難達到想要的靈活性（要求同一份資料可以用兩種不同的表徵圖展示、要求很容易對使用者介面做出改變甚至是在運行時即時作出）

應用後的效果

優勢

1. 同一個 Model ，可以對應多個 View MVC 嚴格分開了 Model 和 UI 組件，因此對於一個 Model ，可以有多個不同的 View 對應它。在運行時，多個 View 甚至可以同時開啟，或是動態開啟關閉。

2. View 可以同步更新 Model 的“變動通知機制”可以保證 Model 變動時，與之相關的介面可以及時給出反應。

3. “可插拔”的 view 和 controller MVC 這三種概念上的區分，讓你可以把與 Model 對應的 View 和 Controller 組件更換掉，甚至是在運行時這麼做都沒問題。

4. 因為 Model 部分和 UI 相關的代碼完全無關，想要移植一個 MVC 程式到新的平台，不需要對核心功能部分做改動，只需要為新平台重新編寫 View 與 Controller 即可。

5. 為“架構”的產生提供了可能，可以基於這個模式建設出一些應用程式架構。

缺陷（喵一眼就行了）

1. 增加了複雜度，某些情況下 MVC 不一定是最好的實現互動式程式的方式。

2. 別喵了，懶得翻了，這部分內容與現在被熟知的 MVC 已經離的有點遠了

淡扯遠之前趕緊收尾。。。

儘管福士對 MVC 的理解到現在有了很多改變（這書快趕上我年齡了），但從前面也可以看到它一以貫之的核心目標：解耦 “Model” 和 “View & Controller”

功能和資料扔進 Model ，View 和 Controller 構成 UI 。這是實踐經驗總結出來的規矩的結果。

為什麼要分開才是重點，現在的系統的互動介面相對於系統功能、資料來說太不穩定，分開它們，可以保證介面的頻繁變動不對穩定的功能資料造成影響。由此給系統提供許多優越的性質。

所以決定一部分代碼寫在哪裡之前，不妨簡單問幾個問題：

1. 如果老闆明天說系統的前端要從瀏覽器換到手機應用，它是能保留在伺服器不更改的那部分嗎？

2. 1 還不能確定的話，考慮這個（砍死老闆不是選項）：如果老闆後天說客戶喜歡複古，不要手機應用了，要用命令列操作一切。這部分代碼還有繼續實現的必要嗎？

答是的話，它應該歸於 model 範疇，但仍可以繼續細化（如其它答案說的將 model 劃分為多個部分，各有側重點）。

架構提供了一個極好的起點，但從不是設計的重點終點，項目演化的過程中見招拆招了。或是你能預判可能出現的問題，提前防範，這也是經驗豐富的人的價值所在，需要逐步積累。

再建一個service層

標準的mvc模式
商務邏輯放model
簡單調用整合放controller
視圖顯示放view

實際開發根據實際情況變動

ps:我不知道為啥那麼多人說controller

感情你的商務邏輯都是放在controller？那太混亂了

tp有個邏輯層'logic'。預設沒有，手動添加。
對外用controller
邏輯用logic
資料處理用model

齊了，無煩惱。

可以給你參考下，現在所做項目的模式，希望有協助到你！用的是tp3.2.3版本的，項目的大致架構是這樣的：

1. model層：主要是一些資料庫的操作；

2. logic層：我們將商務邏輯放到這一層作統一的處理，通過事務的方式來管理，涉及多表操作的問題，這樣整體就比較清晰；這裡說明下，logic會調用model的單一資料操作；

3. controller層：接收和處理資料，單一業務，直接調用model的資料操作就能完成，涉及多個資料表操作的，就調用logic層

肯定是controller呀

controller比較合適

當然是寫在controller。用spring這樣的ioc容器給controller分層，比如分成service層和dao層

TP5的文檔建議放在模型

http://www.kancloud.cn/manual/thinkphp5/122950

看你怎麼架構你自己的程式，可以放在model層中，那麼在設計方法的時候要考慮好拓展性和複用性。放在controller層的話，model層的資料操作就儘可能的原子層級操作。
現在比較喜歡增添一個service層，那麼的話可以讓controller和model層看起來更好看一些

標準的MVC是這樣的。
模型負責資料庫讀寫還有各種商務邏輯。
控制負責接收參數；過濾參數；執行個體化模型；調用方法；渲染模版輸出，或者ajax,或者執行跳轉等等。
但是一旦項目趕進度。直接擼在控制器吧，後期慢慢搬代碼。整合

放哪的都有 看設計者怎麼考慮吧~ 如果還是亂就再抽象一層嘍~

