在MVC分層架構中，Repository類是否是業務層的一部分？

假設您有一個MVC應用程序，其中由實體框架（EF）表示的模型可從數據庫「獲取」數據以及實現所有業務邏輯的動作方法。控制器通過EF從數據庫獲取數據。在MVC分層架構中，Repository類是否是業務層的一部分？

想象一下，現在創建一個放置在Controller和Model之間的存儲庫類。這樣你有：

1）控制器：實現大部分業務邏輯;

2）庫類，負責實現簡單的商業邏輯，在應用中通過的方法將數據提供給每一控制器並從EF獲取數據;

3）模型：EF類從數據庫獲取數據並將它們提供給存儲庫類。

Repository類是業務服務層還是需要在控制器和存儲庫之間添加業務層？在後一種情況下，我們有：

1）控制器：只實現請求詳細說明;

2）業務層：一組負責實施大多數業務邏輯的和每控制器在通過方法的應用提供數據類;

3）庫類：從EF獲取數據和公開方法的業務層用於查詢數據庫;

4）型號：EF類，「獲取」數據庫中的數據並將其提供給庫類。

我不認爲視圖，因爲它是不相關的。我希望有人能爲我明確這個區別。通過Martin Fowler here定義或者至少模式 - 非常感謝

乾杯

弗朗西斯

來源

2011-04-07 CiccioMiami

您所提出的模型和控制器的定義從MVC模式的術語的傳統用法不同。

通常它是包含大部分業務邏輯的模型，Controller負責管理視圖和模型之間的信息流。若要從福勒的文章引用：

控制器的任務是採取用戶的輸入，並找出做什麼它。

看着就到存儲庫應放在你的實際問題，這將是模型內，但包裹在您眼前的數據接入基礎設施的組成部分（幾乎是一個庫是什麼非常清晰）。

因此，模型由兩個關鍵部分組成 - 具有表達性業務邏輯的域對象和執行諸如訪問數據訪問層的服務基礎結構。（另一種常見方法是讓模型由不具備豐富域模型功能的服務組成，但仍包含所有業務邏輯和數據訪問）。

最後一個想法是小心過度思考或抽象這些東西 - 保持儘可能簡單，只有當您確信它會帶來價值時纔會爲您的架構引入新層。例如 - EF本身可以在大多數情況下執行您的Repository的角色，因此直接使用它不需要存儲庫層可以刪除不必要的抽象。

來源

2011-04-07 15:07:37

其實我感到有點困惑。在許多ASP.NET MVC教程中，控制器是包含具有業務邏輯的方法的組件。我也提出了另一個類似的問題，他們回答說，Repository不能有任何業務邏輯。請你看看[這個問題]（http://stackoverflow.com/questions/5581165/add-simple-business-logic-to-repository-in-aspnet-mvc-3-c）並告訴我什麼是正確的方法？謝謝 – CiccioMiami 2011-04-07 15:59:10

@Francesco它當然會有很大的不同，但總的來說，MVC教程忽略了模型，而是將注意力集中在視圖和控制器上。這導致了一種誤解，即該模型純粹是數據和輕量級數據傳輸對象。最佳實踐反而認爲模型是所有業務邏輯的地方*除了圍繞特定視圖及其呈現（這是控制器業務邏輯）。至於你的其他問題，我同意，存儲庫只應該關注抽象數據訪問問題，而不是業務邏輯。 – 2011-04-07 22:26:49

@Francesco：根據DDD的書，我認爲許多ASP.NET MVC教程中的模型都是ViewModel，它主要用於視圖，而不是域模型，我們將把數據和業務邏輯放在一起。 – 2011-04-08 03:43:13

在MVC分層架構中，Repository類是否是業務層的一部分？

回答

相關問題