ActiveRecord下的model作用

現在不少架構都效仿ROR的ActiveRecord，將model直接作為資料庫互動層。而許多業務大都不止針對一張表，有的還包含資料庫之外的邏輯，那麼我只好把這些商務邏輯放在控制器裡處理。
這是不是違背了控制器的原意---串連模型和視圖的橋樑
應不應該在資料模型和控制器之前再增加一個層?
大家是怎麼做的？ 資料庫查詢和業務調用都混在model裡? 有架構能規避能規避這一點嗎?

回複討論(解決方案)

ORM ？
簡單的說，ORM 是把資料庫中的關係資料對應稱為程式中的對象

在 MVC 中 M、V、C 間並無確定的分工界限
所以在 C中完成部分的乃至全部的商務邏輯都是不違規的
就如同將連續的資料離散化一樣，選擇不同的閥值，就可得到不同的結果。

我以為基於 ORM 的架構只是提供了一個雛形，應用的具體的項目時還需要進一步擴充
鑒於應用項目的不可預知性，大多 ORM 都沒有提供關聯或只提供一個介面

所以將 model 從基於 table 改為基於 view 比較好（當然 view 也是不可預知的）

學習。

現在不少架構都效仿ROR的ActiveRecord，將model直接作為資料庫互動層。而許多業務大都不止針對一張表，有的還包含資料庫之外的邏輯，那麼我只好把這些商務邏輯放在控制器裡處理。
這是不是違背了控制器的原意---串連模型和視圖的橋樑
應不應該在資料模型和控制器之前再增加一個層?
大家是怎麼做的？ 資料庫查詢和業務調用都混在model裡? 有架構能規避能規避這一點嗎?

餓哦局的可以把資料庫專門做一層封裝，而model負責處理商務邏輯，需要處理資料的時候調用封裝好的資料庫模組，這樣資料庫模組也可以通用化給不同的model調用，而controller專門做控制，這樣結構也很清晰。

現在不少架構都效仿ROR的ActiveRecord，將model直接作為資料庫互動層。而許多業務大都不止針對一張表，有的還包含資料庫之外的邏輯，那麼我只好把這些商務邏輯放在控制器裡處理。
這是不是違背了控制器的原意---串連模型和視圖的橋樑
應不應該在資料模型和控制器之前再增加一個層?
大家是怎麼做的？ 資料庫查詢和業務調用都混在model裡? 有架構能規避能規避這一點嗎?

餓哦局的可以把資料庫專門做一層封裝，而model負責處理商務邏輯，需要處理資料的時候調用封裝好的資料庫模組，這樣資料庫模組也可以通用化給不同的model調用，而controller專門做控制，這樣結構也很清晰。

餓哦局的=》我覺得

學習.....大牛任務

