问如何在单个Web应用程序中最好地结合web Api和MVC

EN

对于我的业务规则，我通常有另一个层(根据应用程序的大小和复杂性，可以是不同的项目/程序集)。您可以将此业务服务称为，或者其他与您的案例相关的名称。

因此，MVC控制器和应用编程接口控制器都使用这一层；这使应用程序保持干爽。

我个人倾向于只在我的业务层中保留复杂的操作，这意味着如果我需要从我的持久层读取一些东西来显示在我的视图中，我会直接在MVC控制器上进行。这是个人喜好的问题，但我更喜欢CQRS的方式。

因此，MVC控制器将实例化这些业务服务(或者，如果使用IoC，它们将被注入到控制器中)。对于读取操作，您可以选择直接转到您的持久层或使用其他读取策略。

同样的事情也会发生在你的API控制器上，它们将使用这个“公共”服务层。

您不需要在MVC控制器上实例化API控制器。如果您正在开发SPA或类似的应用程序，则可以通过AJAX使用您的Web Api控制器。

没有一种单一的方法来构建你的应用程序，只是有不同的方法，每一种方法都或多或少地伴随着痛苦。

如果您正在考虑在您的应用程序中引入测试(您应该：)；那么您应该以一种易于测试其每个部分的方式来构建它。

就我的两分钱。

Web API的全部要点是成为一个无状态的RESTful服务。如果你做得对，就永远不会有这样的例子。我知道这个问题很老了，你个人可能已经学过了，但答案对你来说并不多，因为它是对一个常见问题的答案。

请注意，当谈到Web时，人们通常谈论的是ApiControllers，而不是基本的MVC“控制器”，这些控制器采用路由并将它们转换为视图。

因此，在您的项目中，您可能有一些“控制器”，它们执行一些基本的视图逻辑，但没有业务逻辑。不要将其与服务层混淆，服务层是业务逻辑和持久性访问的包装器。

我和许多人都认为ApiControllers不应该和你的MVC应用程序混在一起。请记住，MVC与Web API不能很好地混合。正如Filip W所说：

Web API和MVC使用的许多概念，尽管乍一看很相似，但实际上并不兼容。例如，Web属性是System.Web.Http.Filters.Filter，而MVC属性是System.Web.Mvc.Filter -并且它们不能互换。

最灵活的答案

因此，您要做的是创建一个名为api.YourWebsite.com的子域，并在其中构建一个新的Web API ApiController项目。该Web API项目只需通过ApiControllers和依赖注入实例化和公开业务逻辑即可。

备用1

面向服务的体系结构完全是关于可重用性的。如果你想让你的应用程序保持干爽，你绝对应该选择SOA。然而，每种情况都是不同的。如果您永远不会在任何其他应用程序(桌面、安卓、平板电脑、ewPhones等)中使用本网站中的相同业务逻辑，那么您有另一种方法。

将您的业务逻辑层创建为另一个项目，并直接从您的web应用程序访问它。当你的Javascript (Angular/Razor?)控制器发出一个调用，它们可以调用你的ViewModels和/或代码隐藏或类似的东西，这可以实例化业务逻辑并直接访问它。如果所有东西都在那里并且不会被重用，就不需要服务了。

Alternative 2

继续并将您的Web API ApiControllers放入同一个项目中。但是，请确保将它们从MVC“控制器”中分离到不同的文件夹中。尽管如此，当您的Javascript控制器发出调用时，它们会将调用路由到您的网站以实现无状态返回。不要将无状态ApiControllers与您的ViewModels和其他MVC代码混在一起。

这样做的缺点是缺乏SOC。现在，您混合了服务层和UI层，并且您的UI层被强制访问您的业务逻辑层(DLL)。如果Alternative 1做到了，那有什么错呢？

好吧，错误的是，Alternative 1是一个没有增长空间的小应用程序。其他任何东西(原始计划，或这里的备选方案2)都应该有UI，这些UI根本不知道业务逻辑(或持久性)是否存在。他们应该在不知道后端世界的情况下做他们的坏事。