ASP.NET MVC企业DDD架构和WCF层

Question

我使用Domain Driven Design设计了我的ASP.NET MVC应用程序，我得到了以下项目：

• MyApp.Core - 应用核心，包含域模型等。
• MyApp.Infrastructure - app主基础设施，包含使用EF存储（repos等）的域模型的实现。
• MyApp.Web.Core - 域模型，服务声明（接口）等仅适用于Web（例如IFormAuthenticationTicketSupplier，IOAuthAuthenticationProvider等）
• MyApp.Web.Infrastructure - 网络实施
• MyApp.Web.UI - ASP.NET MVC标准应用程序。

此应用程序应由具有多个服务器等的企业使用。目前，应用程序在控制器的基础架构层中调用服务，该服务器使用存储库和EF。我可以使用连接字符串连接到数据库服务器。

在Google上挖掘这个主题时，我读到在创建企业应用程序时采取的一些措施是创建应用服务器和Web服务器。在应用程序服务器中 - 存储WCF服务，并在Web服务器中调用它。

我想知道我是否应该这样做（如果在与企业打交道时创建WCF服务是正确且必需的approch）： - 为什么有人不仅要在控制器中使用服务而是使用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太过抽象了。