Question

我知道在开发MVC应用程序时并不是每个人都使用彻底的架构，但我们假设我有以下架构：

App.Core --> Class Library (POCO or Domain objects)
App.Data --> Class Library (Repository and Entity Framework)
App.Service --> Class Library (Service layer with all business logic)
App.Web --> asp.net MVC 3.0 project

App.Data --> Has a reference to App.Core
App.Service --> Has a reference to App.Core and App.Data
App.Web --> Has a reference to App.Core and App.Service

在我们的MVC应用程序中，我们尝试遵循这种方法：

在我们的Controller（在方法中）中，我们实例化一个ViewModel。
我们从App.Service Layer
填充ViewModel后，我们将其返回到View（所以视图现在是强类型的）。

这种情况发生在99.9％的情况下。它很干净，我们喜欢它，它很好地利用它自己......等等。

现在我的问题如下：

如果我们决定将我们的应用程序移动到MVC 4.0并开始使用新的 Web API 方法，我不确定我完全理解在哪里（或如何）它适合我们当前的架构吗？

请记住，我们愿意改变这种状况！

我们应该创建一个位于App.Service和App.Web之间的新App.WebAPI层吗？这意味着在我们的控制器中，我们不再需要直接调用App.Service而是需要新的App.WebAPI层？

或者，将Web API保留在App.Web层内，并使控制器调用其他APIControllers，然后调用App.Service层？

我不确定这里是否有任何意义......但请随意提出任何建议，因为我对不同的输入感到好奇。

由于

Answer 1

有几个案例需要考虑：

您是否希望将此Web API用作MVC应用程序的服务层和数据访问？如果是，那么你应该从ASP.NET MVC项目中完全删除App.Service的所有引用，并让它查询Web API而不是获取数据。在这种情况下，Web API位于ASP.NET MVC应用程序和数据访问之间。 Web API与服务层对话并通过HTTP协议公开它。

或者您是否希望为您的网站提供可供其他客户端（Web浏览器除外）使用的其他API？在这种情况下，ASP.NET MVC应用程序和Web API位于同一层。两者都查询您的服务层以填充视图模型，只是在MVC应用程序的情况下，您将这些视图模型传递给视图，而视图又将它们转换为HTML，而在Web API层中，您可能使用稍微不同的视图模型但是仍然从您的服务层填充并传递给客户端使用相应的序列化机制（JSON，XML，...）

Answer 2

我知道这已经很晚了，但实际上我正在寻找相同的建议，我找到了这篇文章。

不会“ MVC和Web API都位于同一层”意味着对代码进行更多维护工作，或者可能重复代码？是不是将mvc web视为浏览器客户端？ ..对我而言，将WebAPI作为其他人的唯一层是有意义的，反过来它会调用您的服务层进行处理。

让Web API和MVC直接与服务层对话有什么好处？ Web API不能成为服务层的包装器吗？

了解新的Web API方法

2 个答案: