当 ASP.NET MVC 中有 JsonResult 时，为什么要使用 WCF REST？
我正在构建一个 ASP.NET MVC 应用程序，但仍然认为自己是 ASP.NET MVC 的新手。我有 WCF REST 背景，因此我最初设置了许多服务，基于 jQuery 的客户端将通过 RESTful AJAX 请求调用这些服务。随着我对 ASP.NET MVC 的了解越来越多，我发现了 JsonResult ActionResult 类型，我只需将这些方法添加到控制器中，它的行为就像我的 WCF RESTful 服务一样。
所以我的问题是，JsonResults 是否存在我没有看到 WCF RESTful 服务提供的限制？到目前为止，我还没有看到它，想知道这是否完全消除了我对 WCF REST 功能的需求。
提前致谢！
I'm building an ASP.NET MVC application and still consider myself new to ASP.NET MVC. I come from a WCF REST background, so I initially set up a number of services that my jQuery-based client would call via RESTful AJAX requests. As I learned more about ASP.NET MVC, I discovered the JsonResult ActionResult type, and I can just add these methods to a controller and it behaves just like my WCF RESTful services.
So my question is, is there a limitation to JsonResults that I'm not seeing that WCF RESTful services provides? So far, I haven't seen it and am wondering if this completely eliminates my need for WCF REST functionality.
Thanks in advance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
并不是每个人都在构建 ASP.NET MVC 应用程序......甚至不是每个人都在构建任何形式的 ASP.NET。
WCF REST 是一种完全独立于 ASP.NET 或 Web 的服务技术 - 您可以在没有 IIS 的情况下拥有 WCF REST 服务。
Not everyone is building ASP.NET MVC applications.... not everyone is even building ASP.NET in any shape.
WCF REST is a service technology totally independent of ASP.NET or web - you can have WCF REST services without IIS in sight.
就您而言，我会使用 MVC 进行 REST 实现，但要回答您的问题：
MVC ASP.Net 仅构建为 HTTP。休息不是。表述性状态传输（REST）虽然最常通过 HTTP 定义，但不限于 HTTP 。 WCF 允许您通过非 HTTP 连接进行通信。
除此之外，我同意在 MVC 中实现 REST 更容易、更健壮，尤其是在较新的 MVC Web API 中，但是也就是说，REST 在 WCF 中也占有一席之地，因为 WCF 可以独立存在，而无需HTTP。
编辑：还应该注意的是，WCF 可以在没有 IIS 的情况下独立存在。
In your case, I'd go with MVC for my REST implementation, but to answer your question:
MVC ASP.Net is built to be HTTP only. REST is not. Representational State Transfer, or REST, while most commonly defined over HTTP, is not limited to HTTP. WCF allows you to communicate over non-HTTP connections.
Outside of that, I'd agree that it's easier and more robust to implement REST in MVC and especially in the newer MVC Web API stuff, but that said, REST has its place in WCF as well, because WCF can stand on it's own without HTTP.
EDIT: Also it should be noted that WCF can stand on it's own without IIS.
虽然从技术上来说，REST != HTTP 是正确的，但大多数 REST 服务都使用 HTTP。 Microsoft 正在将其 WCF HTTP/REST 堆栈合并到 ASP.Net 中。从 WCF codeplex 站点查看此页面：
http://wcf.codeplex.com/wikipage ?title=WCF%20HTTP
以及此页面
http://wcf.codeplex.com/discussions/319671
这样做的结果是，如果您想获得最新的 HTTP REST 支持，您肯定应该转向新的 ASP .Net Web API 随 ASP.Net MVC 4 一起提供。
使用这种方法，您的服务可以在 IIS 中工作（显然），但是 也可以自行托管
此外，如果您对现有 WCF 服务（例如自定义身份验证/授权管理器类、自定义令牌处理程序等）的 WIF 进行了任何投资，它们将轻松从 WCF 迁移到 ASP.Net。
最后， MVC 4 是开源的，并接受社区的意见，因此它将快速发展且高质量，并且 MS 因中止而让您陷入困境的风险要小得多。
While it is technically true that REST != HTTP, the majority of REST services are using HTTP. And Microsoft are merging their WCF HTTP/REST stack into ASP.Net. Check out this page from the WCF codeplex site:
http://wcf.codeplex.com/wikipage?title=WCF%20HTTP
And this page
http://wcf.codeplex.com/discussions/319671
The upshot of this is that if you want to get the most up to date HTTP REST support you should definately shift to the new ASP.Net Web API which is shipping with ASP.Net MVC 4.
Using this approach, your services can work in IIS (obviously) but can also be self hosted if you like.
Also, if you have any investments in WIF with your exsiting WCF services (e.g. custom authentication/authorization manager classes, custom token handlers etc.) they will move easily from WCF to ASP.Net.
Finally, MVC 4 is open source, and taking community input, so it will be fast moving and high quality, and the risk of MS leaving you stranded by discontinuing is much less.