是否有理由在 asp.net MVC 上使用 WCF？

Posted 2023-05-07

【中文标题】是否有理由在 asp.net MVC 上使用 WCF？

【英文标题】：Is there a reason to use WCF over asp.net MVC?

【发布时间】：2013-09-19 08:19:27

【问题描述】：

如果我使用 knockout.js 或 angular.js 作为表示层，还假设服务层需要从数据库中写入数据和读取数据，并且它包含业务规则。为什么我应该使用 WCF over asp.net MVC 作为服务层？调用返回 JSON 数据的 MVC 控制器看起来很简单，我想不出使用 WCF 的理由。

【问题讨论】：

WCF 和 MVC 是两个完全不同的东西。 WCF 是一种进程间通信机制，这意味着当同一台机器或不同机器（客户端-服务器应用程序）上的多个进程需要相互通信时使用它。另一方面，MVC 是一种将 UI 与后端逻辑分开的模式。

【参考方案1】：

如果您专门针对 Web 堆栈，ASP.NET MVC + WebApi 将是服务器端的正确组合。

客户端和服务器对 JSON 的固有支持使得基于 JSON 的 API 非常流行。来自大多数提供商的越来越多的公共 API 基于 JSON 或至少支持 JSON。

WCF 可能适用于服务器到服务器的通信，但对于 Web 堆栈，我认为它不适合。如果您需要支持多种传输介质、与 HTTP 以外的协议绑定、支持二进制序列化以提高性能、复杂的安全要求，那么 WCF 可以为您提供帮助。

对于基于 JSON 的 API，我建议您使用 WebApi 而不是使用 MVC 并返回 JsonResult。

【参考方案2】：

WCF 的重点是将获取内容的方式与逻辑本身分开。如果您稍后决定将此逻辑重新用于需要 SOAP 接口或二进制绑定的事物，这将很有帮助。

如果您使用 MVC，并且您将 JSON 硬编码为视图层中的输出，那么您就必须将其用于有线协议。另外，您必须自己编写更多对象的 JSON 序列化。

这在很大程度上取决于您如何构建服务，以及您打算为应用程序放置流控制的位置。例如，假设您正在提交一个表单来保存一些内容。保存内容后，您是否打算控制下一次编码（成功或失败）到客户端的位置？还是您想在服务器上处理该路由决策？

如果它是基于客户端的，那么 WCF 可能更合适，因为您实际上是将控制器和视图层移动到客户端中。而服务器端服务是纯粹的业务和数据服务，实际上它们是“领域模型”。

如果您想在服务器端控制它，那么 MVC 更可能是您正在寻找的，因为您需要一个控制器，并且“视图”层在客户端和服务器之间拆分。但是客户端必须以尊重服务器告诉它做什么的方式编写。客户端变成了一个哑渲染器，服务器告诉它什么时候去一个新的页面。

【参考方案3】：

我会使用 WCF 而不是 MVC，因为使用 WCF，如果您编写适当的 BO 层，您可以轻松地从移动设备、工作流、winform 等访问该层。所有你想要的。 MVC 会将您锁定在操作控制器的范式中。我使用 WCF（通常同时公开soap和rest绑定）从相同的业务对象执行我所有的企业级 n 层应用程序，这提供了最大的灵活性。