9

我知道并不是每个人在开发 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 应用程序中,我们尝试遵循这种方法:

  • 在我们的控制器内部(在一个方法内),我们实例化了一个 ViewModel。
  • 我们从 App.Service 层填充 ViewModel 调用方法
  • 一旦 ViewModel 被填满,我们将它返回给 View(所以现在视图是强类型的)。

这发生在 99.9% 的时间。它很干净,我们喜欢它,它很好地利用了自己……等等!

现在我的问题如下:

如果我们决定将我们的应用程序迁移到 MVC 4.0 并开始使用新的Web API方法,我不确定我是否完全理解它在哪里(或如何)适合我们当前的架构?

请记住,我们愿意改变这一点!

我们是否应该在 App.Service 和 App.Web 之间创建一个新的 App.WebAPI 层?这意味着在我们的控制器内部,我们不再需要直接调用 App.Service 而是调用新的 App.WebAPI 层?

或者,将 Web API 保留在 App.Web 层中,让控制器调用其他 APIController,而后者又会调用 App.Service 层?

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

谢谢

4

2 回答 2

13

有几种情况需要考虑:

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

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

于 2012-03-01T13:36:48.637 回答
1

我知道这已经晚了,但我实际上是在寻找同样的建议,我发现了这篇文章。

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

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

于 2012-09-01T09:38:59.690 回答