在普通的ASP.Net MVC应用程序中使用Web APi的好处

Question

在基于普通CRUD的ASP.NET MVC应用程序中使用Web API有什么好处？我知道使用Web API确实为我们带来了RESTful服务层的好处，但我不赞成更换整个服务层（以及底层的业务和数据访问层），只使用服务来访问数据库。相反，我觉得我们应该在需要时公开少数功能作为服务，以防客户希望支持其他应用程序，如SPA或应用程序的移动版本。

问题在于，在我的情况下，大部分工作是否将复杂的html视图主要返回到一个应用程序，而内部操作主要是CRUD，也许某些业务逻辑是否有意义去寻求完整的服务层？由于必须创建代理，是否存在任何性能问题。这种架构在扩展方面有什么好处？太多问题。只是困惑。我没有看到需要，但也许我错过了什么？

拥有SOA的想法似乎很好，但担心如果性能下降。

Answer 1

我认为，在网站和Web API之间共享业务逻辑库比让服务器端网站代码调用Web API更好。

HTTP是针对低延迟和独立发展的组件进行协议优化的。如果同一个团队同时控制网站和Web API，并且它们同时部署，并且它们都位于同一个数据中心，则使用HTTP进行相互通信几乎没有价值。

如果您尝试使用Web API向网站提供数据，您将面临的另一个问题是，您可能会构建一个在您的数据中心中正常工作的健谈Web API，但是当远程客户端尝试使用它时，您可以有性能问题。

如果您希望第三方使用的Web API高效且有效，则应构建它们以公开用例，而不是您的网站需要访问的域实体。

Answer 2

在两种情况下，WebAPI对你来说是个好主意：

1. 其他应用程序可能需要访问相同的数据，您只需要编写一次业务逻辑/数据访问逻辑。
2. 您希望编写浏览器端的javascript，将AJAX调用回应用程序的服务器端以检索数据。

对于＃2，您也可以使用常规的MVC和JsonResponse处理程序。在我的应用程序中，我使用两者如果我只是返回数据并且我想直接序列化我的模型对象，我将设置一个WebAPI控制器。但是如果我需要通过Razor模板运行模型，我的控制器上有一个扩展方法，它允许我将视图呈现为字符串，然后我将它作为一个属性返回到JSON对象中，并为其他任何属性设置我需要返回的元数据，如成功代码，错误消息，序列化异常对象等。