ASP.NET MVC企業DDD架構和WCF層

Question

我desgined使用領域驅動設計我的ASP.NET MVC應用程序，我得到了以下項目：

• MyApp.Core - 應用程序的核心，包含域模型等
• MyApp.Infrastructure - 應用主要infrastrucutre，包含實施使用EF域模型存儲（回購等）。
• MyApp.Web.Core - 域模型，服務聲明（接口）和這種僅針對網絡（例如IFormAuthenticationTicketSupplier，IOAuthAuthenticationProvider等）
• MyApp.Web.Infrastructure - Web實現
• MyApp.Web.UI - ASP.NET MVC標準應用程序。

該應用程序應該由具有多個服務器等的企業使用。目前，應用程序在使用存儲庫和EF的控制器的基礎結構層中調用服務。我可以使用連接字符串連接到數據庫服務器。

當挖約在谷歌這個話題，我讀過，創建企業應用程序時，採取了一些approches是創建一個應用程序服務器和Web服務器。在應用程序服務器中 - 存儲WCF服務，並在Web服務器中調用它。

我想知道我是否應該這樣做（如果創建一個WCF服務是正確的，並與企業打交道時，需要計算策略）： - 爲什麼有人不只是使用服務中的控制器，轉而使用API？ - 如果我使用API​​，它不會減慢響應速度？因爲即使電腦在同一網絡上，我仍然會打開一個HTTP請求。 - 如果我應該使用WCF或ASP.NET WebAPI？

感謝您的任何意見和幫助！

Answer 1

首先，關於您的項目，是否有必要分裂MyApp.Web.Core，MyApp.Web.Infrastructure和MyApp.Web.UI？當然，他們可能是單獨的責任，但有時候依賴性衛生勝過封裝。您始終可以將它們留在單獨的文件夾和名稱空間中。除非我需要從別處引用它作爲圖書館，否則我不會將其提取到單獨的項目中。

至於應用服務，這也取決於你的需要。如果唯一可以調用該應用程序服務的地方是ASP.NET MVC應用程序，那麼提取應用程序服務就沒有多少必要了。但是有一些好處。一個是你不必擔心服務所需的所有依賴關係 - 你只需通過Url引用它。當然，你可以從控制器以外的地方調用服務，儘管MVC控制器也可以作爲一個純粹的HTTP服務。您還可以在不發佈MVC應用程序的情況下將更新部署到特定服務。但是你有負擔維護一個單獨的服務。如果你確實走這條路線，那麼使用WebAPI，WCF就太抽象了。