MVC中的業務規則在哪裏

Question

現在大家都在談論MVC，我注意到業務規則沒有得到解決。在三層架構的舊時代，業務規則處於中間層。他們在哪裏落入新的MVC？

Answer 1

起初，我會說他們屬於模型。 MVC Entry on Wikipedia似乎同意：「在MVC中，模型表示應用程序的信息（數據）和用於操縱數據的業務規則」。 畢竟，按照「業務規則」，我們指的是對應用程序涉及的域進行編碼的功能算法和邏輯，而不是與輸入/輸出相關的邏輯。這些與業務相關的核心邏輯不會 - 也不應該 - 根據向用戶顯示的內容（這是View的領域）或用戶輸入（主要由控制器接收）進行更改。

根據我的經驗，在軟件開發過程中提出這樣一個問題非常明顯：我們發現了很多被某些人認爲是「業務規則」的事情，但事實證明是另外一回事。如果它不是真正的商業規則，它可能不屬於該模型。

Answer 2

來自維基Article引述：

MVC常見於Web應用程序，其中，所述視圖是實際的HTML頁面，並且所述控制器可收集動態數據並生成HTML中的內容的代碼。最後，模型由實際內容表示，通常存儲在數據庫或XML節點和業務規則中，該規則根據用戶操作轉換該內容。

Answer 3

你有什麼理由不能混合使用MVC和Ntier嗎？我們的應用程序就是這樣。我們的控制器用於數據驗證並決定進行哪些業務層調用。

OurApp.Web - Asp.net MVC項目
OurApp.Business - 業務層圖書館
OurApp.DataAccess - 數據層圖書館
OurApp.Entities - 基本上所有的 '模型' 的所有圖層共享

Answer 4

業務規則總是存在於模型中。該模型是您可以用完全不同的用戶界面重新使用的一點。該視圖顯然完全依賴於UI選擇，控制器必須從模型中獲取數據並告訴視圖進行渲染。

將業務邏輯放入視圖很糟糕，因爲它將結構與演示文稿聯繫在一起。

將業務邏輯放入控制器是不好的，因爲它將您的業務域分割爲由模型持久保留的數據和控制器中的規則。

Answer 5

你永遠不會看到MVC地址「業務規則」的原因是，MVC大體上是一種演示模式。它着重於如何構建您的應用程序。例如，模型可以被認爲是演示模型。您的應用程序的模型，視圖然後呈現。

但是，爲了創建演示文稿模型，您通常需要轉到所有業務邏輯所在的域模型。在那個時候，MVC並不指定代碼的物理位置。它在另一層？ MVC不關心。

Answer 6

你們錯了控制器中的商業規則，而不是模型......

Answer 7

業務規則應該在模型中，而不是控制器。控制器和視圖是表示層的一部分。

模型表示該域的實體和功能..

控制器僅僅是用於拍攝用戶輸入和請求，執行動作中/上的模型和映射管理器視圖中演示層。控制器不僅僅是一箇中介，視圖OR控制器可能會對模型採取行動。

Answer 8

我認爲這個問題是一個定義問題。在我看來，按照所需順序顯示屏幕的邏輯是一個控制器問題，我看到一些項目使用規則引擎來確定順序以及用戶需要輸入的內容。這與業務規則不完全相同。

Answer 9

這是一個古老發佈的問題，但我喜歡規則存儲庫以完全獨立於應用程序的任何部分。多個應用程序（業務層的多個實現）應該能夠訪問業務規則庫的靜態呈現。簡單的分離決定，例如這樣就可以從桌面 - > web進行遷移，例如微不足道的。

在我的體系結構中，查看 - >模型 - >控制器 - >業務層 - >規則存儲庫，即控制器訪問業務層/層提供的粗糙數據，將其提供給模型，形式，並且視圖被動地顯示它。業務層可以在任何表示格式中重複使用，將具有明確的規則並可以通過隱式規則訪問子系統。按照設計，每個組件都不知道其上面組件的細節。