MVC應用程序架構的數據流

Question

試圖在MVC應用程序中驗證數據流的方法，我正在清理和簡化（在一些重構之后）當前的事情如下圖所示（數據流由箭頭指示）。 並編寫了一些部分來訪問跳過圖層的存儲庫服務。 （就像直接訪問存儲庫服務以查找數據的HTML幫助程序一樣）

幾個問題。

1. 這是一個典型的設計，有任何陷阱嗎？
2. 是否可以跳過瑣碎事物的圖層？
3. 數據流在架構上是否健全？

Answer 1

1. 這似乎是一種常見的設計。 不幸的是，我沒有足夠的經驗指出設計的缺陷，因為我目前的項目是我第一次體驗這種架構。

2. 如果您說存儲庫服務是在多個層中訪問的，那么您是不是錯過了幾個箭頭？ 理想情況下，您不希望從控制器（或Razor幫助程序）訪問您的存儲庫，因為這會使您的代碼更緊密地耦合並使您的關注點分散。 但是，這並不是說在多個模塊中擁有一些有限的存儲庫訪問權限是很糟糕的。 最佳實踐是將這些存儲庫調用移動到業務邏輯中，然后從那里將其傳遞給控制器​​。

3. 我目前使用的ASP.NET項目使用的是非常相似的架構，我們正在取得成功。

Answer 2

似乎已經相當不錯了。

通常我有以下分層：

• 表示層 ：包含帶有模型，控制器，視圖和視圖模型的MVC網站。
• 服務層 ：包含暴露於表示層中所有內容的服務（以WCF服務或Web API的形式，甚至只是一個類庫）。
• 應用程序層 ：包含應用程序邏輯，在我的例子中，這些是使用底層域模型和基礎結構服務的命令和查詢處理程序。
• 域層 ：域實體和服務，與其他層沒有依賴關系，並包含域邏輯。
• 基礎設施層 ：包含基礎設施問題，如數據訪問，日志記錄等......

為了最小化依賴性，我對接口進行編程; 其中具體實現由IoC容器注入。 這意味着每個組件也都是非常可測試的。

表示層的控制器很薄，僅使用服務層（和基礎結構層）。

這是一種非常靈活的方法，但又足夠簡單，適用於大多數類型的應用程序。 此外，如果您使用實體框架，您可能想要考慮您是否確實需要存儲庫和工作單元。