MVC Web應用程序的域驅動設計與數據庫驅動設計

我正在將舊的Web窗體應用程序擴展/轉換爲全新的MVC應用程序。無論是在技術還是業務用例方面，這種擴張都是如此。遺留應用程序是一個很好的數據庫驅動設計（DBDD）。因此對於例如如果你有不同類型的員工，比如操作員，主管，店主等等，你需要添加一個新類型，你只需要在幾張表中添加一些行，然後你的用戶界面自動添加/更新新的員工類型。然而，分層不太好。MVC Web應用程序的域驅動設計與數據庫驅動設計

新的項目有兩個主要目標

可擴展性（對於當前和未來的管道需求）
性能

我打算創建新項目代替數據庫驅動設計（DBDD ）與域驅動設計（DDD）保持擴展性要求。但是，如果將數據庫驅動設計與傳統DBDD應用程序的性能進行比較，那麼從數據庫驅動設計轉向域驅動設計似乎會對性能要求產生負面影響。在遺留應用程序中，來自UI的任何數據調用都將直接與數據庫進行交互，並且任何數據都將以DataReader或（某些情況下）DataSet的形式返回。

現在，對於嚴格的DDD，任何數據調用都將通過業務層和數據訪問層進行路由。這意味着每次調用都會初始化一個業務對象和一個數據訪問對象。一個UI頁面可能需要不同類型的數據，這是一個Web應用程序，每個頁面都可以被多個用戶請求。另外一個MVC Web應用程序是無狀態的，每個請求都需要每次都初始化業務對象和數據訪問對象。因此，對於MVC無狀態應用程序來說，DBDD對於性能而言更喜歡DDD。

或者在DDD中有一種方法可以實現DDD提供的擴展性和DBDD提供的性能？

來源

2012-05-21 devanalyst

由於它從字面上理解各種設計背後的機制，因此成爲一個有趣的問題。很多時候，這些討論太抽象而無用。這是非常直接的。我很想看看答案是什麼（我自己也不知道）。 –

在開始思考之前，我有幾個問題： 1.性能要求究竟是什麼？應用程序的響應速度有多快。是否應該在1秒內迴應所有查詢，或者0.5秒內獲取數據，1秒後更新？ 2.您是否已經有一些當前應用程序的指標，以及基於MVC的應用程序工作速度會有多慢？ –

我有當前應用程序數據庫操作的指標。除了報告可能會有複雜且數據量大的操作並且可能需要幾分鐘的時間外，CRUD需要不到一秒的時間，而在數據庫級別的2到3秒內發生最大數據獲取操作。 MVC應用程序的速度要慢多少，問題是關於 – devanalyst

您是否考慮過某種形式的Command Query Seperation，其中更新是通過域模型進行的，但讀取是作爲DataReaders進行的？全面的DDD並不總是合適的。

來源

2012-05-21 12:05:51 Chriseyre2000

+ 1用於推薦CQRS。雖然我不得不說，使用CQRS並不意味着你不再使用'全面的DDD'。恰恰相反。從您的域聚合中投影DTO /查看模型，而不是直接從數據庫中投射它們，這不會降低您正在練習的DDD級別。做前者只會使自己的生活變得艱難，並且需要根據（或應該）設計在交易中強制實施的不變量的對象進行映射。後者對我來說，就是實用/合理的方式。 –

這不能解決批量寫入查詢。而且它也不能解決問題，有時候你只需要使用ID，並且不需要保存所有內容（用於性能）。您可以爲每個實體添加規則，但是您肯定會獲得寫入操作，這些操作將涉及寫入與多個實體有關的數據（不管它們是否爲聚合）並且您需要複製這些規則，因爲您是避免循環遍歷每個實體來單獨應用它的規則（打敗DDD的目的）。 – prograhammer

這裏有一個很好的[文章]（http://blog.sapiensworks.com/post/2013/12/16/Bulk-Actions-With-DDD-And-CQRS.aspx/），解決我提到這個問題。我不知道解決方案是否能夠充分解決問題。這是一個艱難的課題。 CQRS有幫助，但我們在寫入方面仍然有性能問題需要處理。 – prograhammer

在您的方案中使用DDD不應該有重大的性能影響。你擔心的事情似乎更像是一個數據訪問問題。你把它稱作

初始化一個業務對象和數據訪問對象

爲什麼「初始化」貴嗎？你使用什麼數據訪問機制？

存儲在關係數據庫中的長壽命對象的DDD通常使用ORM實現。 如果正確使用，ORM對大多數應用程序的性能影響很小（如果有的話）。如果存在已證實的瓶頸，您可以隨時將應用程序中性能最敏感的部分切換回原始SQL。

NHibernate只需要在應用程序啓動時初始化一次，之後它使用與常規數據讀取器相同的ADO.NET連接池。因此，這一切都歸結爲一個適當的映射，獲取策略，並避免像'n + 1選擇'這樣的經典數據訪問錯誤。

來源

2012-05-23 03:51:10 Dmitry

「現在有了嚴格的DDD，任何數據調用都將通過業務層和數據訪問層進行路由。」

我不相信這是真的，這當然不實際。我相信這應該閱讀：

現在嚴格DDD到位，任何呼叫的交易將通過業務層和數據訪問層路由。

沒有什麼說你不能直接調用數據訪問層來獲取需要顯示在屏幕上的任何數據。只有當您需要修改需要調用基於行爲設計的域模型的數據時。在我看來，這是一個關鍵的區別。如果您通過域模型路由所有內容，您將遇到三個問題：

時間 - 實現功能需要很長時間，沒有任何好處。
模型設計 - 您的領域模型將被彎曲變形以滿足查詢而不是行爲的需求。
性能 - 不是因爲有額外的圖層，而是因爲您無法像直接從查詢中那樣快速地從模型中獲取聚合數據。即考慮爲特定客戶提交的所有訂單的總價值 - 爲此編寫查詢的速度比爲客戶提取所有訂單實體的速度快得多，迭代和求和。

正如Chriseyre2000所提到的，CQRS旨在解決這些確切的問題。

來源

2012-05-25 10:51:16

MVC Web應用程序的域驅動設計與數據庫驅動設計

回答

相關問題