1

我已经使用域驱动设计设计了我的 ASP.NET MVC 应用程序，并且我得到了以下项目：

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

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

在 Google 研究这个主题时，我读到创建企业应用程序时采用的一些方法是创建应用程序服务器和 Web 服务器。在应用程序服务器中 - 存储 WCF 服务，而在 Web 服务器中只是调用它。

我想知道我是否应该这样做（如果在与企业打交道时创建 WCF 服务是正确且必需的方法）： - 为什么有人不应该只使用控制器中的服务而是使用 API？- 如果我使用 API，它不会减慢响应速度吗？因为即使计算机在同一个网络上，我仍然会打开一个 HTTP 请求。- 如果我应该使用 WCF 或 ASP.NET WebAPI？

感谢您的任何反馈和帮助！

4

1 回答 1

2

首先，关于您的项目，是否需要拆分 MyApp.Web.Core、MyApp.Web.Infrastructure 和 MyApp.Web.UI？当然，它们可能是单独的职责，但有时依赖卫生胜过封装。您始终可以将它们放在单独的文件夹和命名空间中。我不会将某些内容提取到单独的项目中，除非我需要从其他地方将其作为库引用。

至于应用程序服务，这也取决于您的需求。如果调用该应用程序服务的唯一地方是 ASP.NET MVC 应用程序，那么就没有太多需要提取应用程序服务。不过也有一些好处。一是您不必担心服务所需的所有依赖项 - 您只需通过 Url 引用它。当然，您可以从控制器以外的地方调用服务，尽管 MVC 控制器也可以充当纯 HTTP 服务。您还可以在不发布 MVC 应用程序的情况下将更新部署到特定服务。但是您确实有维护单独服务的负担。如果您确实走那条路，请使用 WebAPI，WCF 实在是太抽象了。

于 2013-04-08T15:26:24.373 回答