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就太抽象了。