我即将创建一个简单的 Web 应用程序，我想知道是否应该使用 ASP.NET MVC 4 新功能Web API。
最好的方法是什么？
我做了一些研究，发现有两种选择：
Option 1
将 Web Api 设为我的服务层并从控制器调用它以读取/写入数据，并使用视图模型和剃刀渲染视图。
Option 2
将 Web Api 设为我的服务层，并使用 Javascript 从视图中直接调用它。
我不是它的忠实粉丝，Option 2因为我觉得我忽略了仅用于页面之间重定向的控制器。此外，我更喜欢使用 razor 而不是 Javascript。
如果我选择Option 1，我是否必须在控制器中创建一个 Web API 的实例？因为这感觉就像我做错了什么。
最好的选择是什么？还有其他我没有考虑过的选择吗？
如果您能提供一些可以帮助我的参考资料或书籍，我将不胜感激。
谢谢。
我的业务规则通常有另一层（根据应用程序的大小和复杂性，可以是不同的项目/程序集）。您可以将此业务服务称为业务服务，或任何适用于您的情况的名称。
所以MVC 控制器和API 控制器都使用这一层；这使应用程序保持干燥。
我个人更喜欢只在我的业务层中保留复杂的操作，这意味着如果我需要从我的持久层中读取一些内容以显示在我的视图中，我会直接在 MVC 控制器上进行。这是个人喜好问题，但我更喜欢采用CQRS方式。
因此，您的 MVC 控制器将实例化这些业务服务（或者如果您使用 IoC，它们将被注入到您的控制器中）。对于读取操作，您可以选择直接进入持久层或使用其他读取策略。
你的 API 控制器也会发生同样的情况，它们将使用这个“通用”服务层。
您不需要在 MVC 控制器上实例化 API 控制器。如果您正在开发 SPA 或类似内容，则可以通过 AJAX 使用您的 Web Api 控制器。
没有单一的方法来构建您的应用程序，只有不同的方法，每一种方法或多或少都会带来痛苦。
如果你正在考虑在你的应用程序中引入测试（你应该:)）；那么你应该以一种易于测试它的每个部分的方式来构建它。
只是我的2美分。
Web API 的全部意义在于成为一个无状态的 RESTful 服务。如果你做得对，就永远不会有这样的例子。我意识到这个问题很老，您可能已经亲自了解了这一点，但是对于您来说，答案并不像对常见问题的回答那样多。
请注意，当谈到 Web API 时，人们通常在谈论 ApiControllers 而不是基本的 MVC“控制器”，它们采用路由并将它们转换为视图。
因此，在您的项目中，您可能有一些“控制器”，它们执行一些基本的视图逻辑，但没有业务逻辑。不要将其与您的服务层混淆，后者是您的业务逻辑和持久性访问的包装器。
我和许多人认为 ApiControllers 不应该与您的 MVC 应用程序混合使用。请记住，MVC 不能与 Web API 很好地混合。正如菲利普 W 所说：
Web API 和 MVC 使用的许多概念，尽管乍一看很相似，但实际上并不兼容。例如，Web API 属性是 System.Web.Http.Filters.Filter 和 MVC 属性是 System.Web.Mvc.Filter - 它们是不可互换的。
最灵活的答案
所以你要做的是创建一个名为 api.YourWebsite.com 的子域，并在那里构建一个新的 Web API ApiController 项目。该 Web API 项目应该做的只是通过 ApiControllers 和依赖注入实例化和公开业务逻辑。
备选方案 1
面向服务的架构是关于可重用性的。如果您想保持您的应用程序 DRY，那么您绝对应该使用 SOA。虽然，每种情况都不同。如果您永远不会在本网站的任何其他应用程序（桌面、安卓、平板电脑、ewPhones 等）中使用相同的业务逻辑，那么您有另一种方法。
将您的业务逻辑层创建为不同的项目，并直接从您的 Web 应用程序访问它。当您的 Javascript（Angular/Razor？）控制器进行调用时，它们可以调用您的 ViewModel 和/或 Codebehind 或类似的东西，它们可以实例化业务逻辑并直接访问它。如果一切都在那里并且不会被重用，则不需要服务。
备选方案 2
继续，将您的 Web API ApiControllers 放在同一个项目中。但是，请确保将它们与 MVC“控制器”分开到不同的文件夹中。尽管如此，当您的 Javascript 控制器进行调用时，它们仍将对您的网站进行路由调用以进行无状态返回。不要将无状态 ApiController 与您的 ViewModel 和其他 MVC 代码混合使用。
这样做的缺点是缺少 SOC。现在您已经混合了服务层和 UI 层，并且您的 UI 层被迫访问您的业务逻辑层 (DLL)。如果备选方案 1 做到了，那有什么问题？
好吧，问题在于备选方案 1 是一个没有增长空间的小型应用程序。其他任何东西（原始计划，或此处的备选方案 2）都应该具有不知道业务逻辑（或持久性）是否存在的 UI。他们应该在不知道后端世界的情况下做他们的小事。