1

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

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

拥有 SOA 的想法似乎不错，但担心它是否会降低性能。

4

2 回答 2

3

我相信在网站和 Web API 之间共享业务逻辑库比让服务器端网站代码调用 Web API 更好的选择。

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

如果您尝试使用 Web API 向您的网站提供数据，您将面临的另一个问题是，您可能会构建一个在您的数据中心运行良好的健谈 Web API，但是当远程客户端尝试使用它时，您可能会遇到性能问题.

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

于 2013-10-18T12:19:09.117 回答
1

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

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

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

于 2013-10-17T19:29:14.447 回答