1

在 MVC Web 服务而不是 asmx 和 WCF Web 服务中工作有什么用处。谁能说说这三者的区别？

4

4 回答 4

1

关于 WCF Web 服务和 ASPNET Web 服务 (ASMX)，您可以从 MSDN 中找到并排比较：Comparing ASP.NET Web Services to WCF Based on Development

如果您正在制作 MVC 应用程序，您可以同时使用 ASMX 和 WCF Web 服务，但我强烈建议在任何新开发中使用 WCF Web 服务。

有关信息，我认为比较适合的博客是：ASMX Vs WCF

WCF 与 ASMX

协议支持

WCF

  • HTTP
  • TCP
  • 命名管道
  • MSMQ
  • 风俗
  • UDP

ASMX

  • 仅 HTTP

托管

ASMX

  • 只能使用 IIS 上的 HttpRuntime 托管。

WCF

  • WCF 组件可以托管在 .NET 3.0 中的任何类型的环境中，例如控制台应用程序、Windows 应用程序或 IIS。
  • WCF 服务被称为“服务”而不是 Web 服务，因为您可以在没有 Web 服务器的情况下托管服务。
  • 自托管服务使您可以灵活地使用 HTTP 以外的传输方式。

WCF 向后兼容性

  • WCF 的目的是为分布式应用程序提供统一的编程模型。
  • 向后兼容性
  • WCF 采用现有技术堆栈的所有功能，而不依赖其中任何一个。
  • 使用这些早期技术构建的应用程序将继续在安装了 WCF 的系统上保持不变。
  • 现有应用程序可以使用 WCF 进行升级
  • 新的 WCF 事务应用程序将与基于 System.Transactions 构建的现有事务应用程序一起使用

WCF 和 ASMX 集成

  • WCF 可以使用 WS-* 或 HTTP 绑定与 ASMX 页面进行通信

ASMX 的限制：

  • ASMX 页面不会告诉您如何通过传输传递它并使用特定类型的安全性。这是 WCF 显着增强的东西。
  • ASMX 与 HTTP 运行时紧密耦合，并且依赖于 IIS 来托管它。WCF 可以由任何能够承载 .NET Framework 3.0 的 Windows 进程承载。
  • ASMX 服务在每次调用的基础上进行实例化，而 WCF 通过提供各种实例化选项（例如单例、私人会话、每次调用）为您提供了灵活性。
  • ASMX 提供了互操作性的方式，但它不提供或保证端到端的安全性或可靠的通信。
于 2012-10-26T07:29:16.097 回答
0

我是维护ServiceStack的核心团队的一员，这是在 .NET / Mono 上构建基于 REST 的服务的另一个非常流行的选择。

支持基于 REST、SOAP 和 MQ 的服务

除了基于 REST 的服务之外，您还可以重复使用相同的服务来支持 SOAP 和基于 REST 的端点。ServiceStack 还包括 .NET 最快的JSON、JSV 和 CSV 文本序列化程序。这是一个较早的答案，比较了它相对于 WCF 和 WebApi 的优势。

简洁、类型化、端到端的 API

ServiceStack 还包括所有主要支持格式的类型化通用服务客户端，包括：JSON、XML、JSV、SOAP 1.1/1.2 以及超快速二进制ProtoBuf和MessagePack格式。

ServiceStack 的通用服务客户端提供最简洁、类型化的端到端客户端/服务器 API，无需任何代码生成。

ServiceStack 概览幻灯片

今年的ServiceStack Overview Talk MonkeySpace很好地介绍了 ServiceStack 及其优势。

于 2012-11-03T19:11:44.113 回答
0

关于 WCF 优于 ASMX 的优点，我无法在此处的其他帖子中脱颖而出，它来自源代码（微软），我将添加到该帖子中，因为它没有提及 MVC Web API，这是......你的问题实际上取决于您要解决的问题。如果您尝试进行消息传递、消息队列或较低级别的 tcp/ip，它仍然是 WCF..

我是一个现代世界的程序员，尽管他们来得那么懒惰.. ASMX 和 WCF 技术对我来说开始有点过时了，例如，一个典型的 WCF 实现可能会有一个与之关联的大量 XML 配置，如果这是你习惯的工作方式，那么它可能会感觉很自然。

我喜欢类型安全，讨厌魔术字符串，更讨厌在大型 XML 中挖掘，在我看来，这是运行时错误的路径。

如果您使用 MVC 框架创建了 Web 应用程序，那么使用 mvc webapi 的学习曲线几乎为零。

所有标准的东西，如路由、模型和控制器，仍然以完全相同的方式应用，所有的 HTTP 动词都可以使用......

只需最少的努力，您的所有路由和控制器都可以以完全类型安全的方式（无字符串）使用，所以如果它被破坏，那么它可能无法编译......

此外，编写单元测试来练习控制器比单元测试 ServiceContract容易得多

我不确定，但出于与上述相同的原因，我希望 MVC 路线比 WCF 更适合 IoC/DI，但我准备在这方面犯错。

你能说我有偏见吗？

于 2012-10-26T07:51:28.200 回答
0

这是一个主观问题，关于 3; WCF 更适合层与层之间的通信，asmx 基本上是我们在 wcf 出现之前使用的，并且由于 mvc 的灵活性，它可以在许多场景中使用。然而，WCF 非常适合实现 OData 服务。

我个人使用 MVC 在客户端层上为 AJAX 交互实现 Web 服务，并且已经在几个项目中这样做了。优点是我没有单独的项目，因此前端堆栈重量轻且干燥，更高效，以这种方式组织代码对我来说更符合逻辑。

恕我直言 wcf 的开销太大，对于简单的 JSON 序列化来说过于复杂。我个人认为在 n 层架构站点中使用 MVC 而不是 WCF 是有道理的。

本文着眼于在臭名昭著的 NerdDinnerd 项目书呆子晚餐休息中使用它

有几个框架，例如 OpenRasta，但我发现标准的 mvc.net 工具绰绰有余。

此外，haacked 的一篇好文章在这里：haacked.com

于 2012-10-26T08:21:00.837 回答