7

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

4

3 回答 3

6

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

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

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

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

于 2013-09-15T08:00:48.947 回答
4

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

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

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

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

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

于 2013-09-15T00:37:32.497 回答
2

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

于 2013-10-19T18:49:33.510 回答