WCF 提高了标准还是仅仅提高了复杂性级别？

StackOverflow https://stackoverflow.com/questions/50114

  •  09-06-2019
  •  | 
  •  

题

我了解 WCF 提供的三部分服务/主机/客户端模型的价值。但这只是我的问题还是 WCF 似乎采取了一些非常直接和直接的东西（ASMX 模型）并把它弄得一团糟？

是否有其他方法可以使用 SvcUtil 的命令行回退来生成代理？通过 ASMX 服务，自动提供测试工具；现在 WCF 有更好的替代方案吗？

我很欣赏 WS* 的东西与 WCF 更紧密地集成，并希望在那里找到 WCF 的一些回报，但是天哪，否则我会感到困惑。

此外，WCF 的可用书籍状况充其量也很糟糕。Juval Lowy 是一位出色的作者，他写了一本很好的 O'Reilly 参考书“Programming WCF Services”，但对于现在学习使用 WCF 来说，它并没有多大作用（无论如何对我来说）。该书的前身（作为教程，组织得更好一些，但不多）是 Michele Leroux Bustamante 的《Learning WCF》。它有一些不错的地方，但已经过时了，相应的网站也消失了。

除了继续 Google 搜索之外，您是否还有好的 WCF 学习参考资料？

有帮助吗？

解决方案

好的，我们开始吧。首先，Michele Leroux Bustamante 的书已针对 VS2008 进行了更新。这本书的网站并没有消失。它现已上线，并且包含大量精彩的 WCF 信息。在该网站上，她为书中的所有示例提供了与 VS2008 兼容的更新代码。如果您从亚马逊订购，您将获得更新的重印本。

WCF 不是 仅有的 ASMX 的替代品。当然它可以（并且做得很好）取代 ASMX，但真正的好处是它允许您的服务自托管。WSE 的大部分功能从一开始就已内置。框架是 高度 可配置，并且通过多种协议为多个端点提供服务的能力令人惊叹，IMO。

虽然您仍然可以通过“添加服务引用”选项生成代理类，但这不是必需的。您真正需要做的就是复制您的 ServiceContract 接口并告诉您的代码在哪里可以找到服务的端点，仅此而已。您可以使用很少的代码从服务调用方法。使用此方法，您可以完全控制实施。无论您选择哪种方法来生成代理类，Michele 都会显示这两种方法并在她的中使用这两种方法 出色的 关于该主题的一系列网络广播。

米歇尔拥有大量精彩材料，我建议您查看她的网站。以下是一些在我学习 WCF 时对我非常有帮助的链接。我希望您能够认识到 WCF 的真正强大之处以及实现起来是多么容易。学习曲线有点陡峭，但您的时间投入的回报是非常值得的：

我建议您至少观看 1 场 Michele 的网络广播。她是一位非常高效的演讲者，并且在 WCF 方面她的知识渊博。她出色地从头开始揭开了 WCF 内部运作的神秘面纱。

其他提示

我很难判断何时应该或会使用 WCF。为什么？因为我把生产力和简单性放在首位。为什么 ASMX 模型如此成功，因为它有效，而且你可以让它快速工作。通过 VS 2005 和 .NET 2.0，wsdl.exe 可以提供非常漂亮且兼容的服务。

在现实生活中，您的架构中应该只有很少的通信协议。这使其简单且易于维护。如果您需要访问遗留系统，请为它们编写特定的适配器，以便它们可以在光鲜亮丽的 SOA 世界中运行。

WCF 比 ASMX 强大得多，并且它以多种方式对其进行了扩展。ASMX 仅限于 HTTP，而 WCF 可以使用多种协议进行通信（当然，HTTP 仍然是大多数人使用它的方式，至少对于需要互操作的服务而言）。WCF 也更容易扩展。至少，可以用ASMX无法扩展的方式来扩展它。“简单”可能有点夸张。=)

在我看来，WCF 提供的附加功能远远超过了它所增加的复杂性。我也觉得编程模型更简单了。例如，DataContracts 比必须使用 XML 序列化以及所有内容的公共属性进行序列化要好得多。它本质上也更具声明性，这也很好。

等待....您曾经使用过 .NET Remoting吗？因为这才是它所取代的真正东西。.NET Remoting 本身相当复杂。我发现 WCF 更简单，布局也更好。

我没有看到它经常被提及，但是你 能 仍然使用 WCF 实现相当简单的服务，与 ASMX 服务非常相似。例如：

[ServiceContract]
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class SimpleService
{
    [OperationContract]
    public string HelloWorld()
    {
        return "Hello World";
    }

}

您仍然需要在 web.config 中注册端点，但这还不错。

消除单独的数据、服务和操作合同的冗长性对于使 WCF 对我来说更易于管理大有帮助。

VS2008 包含“添加服务引用”上下文菜单项，它将在幕后为您创建代理。

如前所述，WCF 不仅仅旨在替代 ASMX Web 服务类型，而是为所有可互操作的服务提供一致、安全且可扩展的方法，无论是通过 HTTP、tcp、命名管道还是 MSMQ 传输。

我承认我确实对 WCF 存在其他问题（例如通过 basicHTTP 公开服务时重写方法签名 - 请参阅 这里, ，但总的来说我认为这是一个明确的改进

如果您使用 VS2008 并创建一个 WCF 项目，那么当您点击运行/调试时，您会自动获得一个测试工具，并且您可以添加引用而无需使用 svcutil。

我最初对WCF的想法一模一样！以下是一些解决方案：

  1. 使用泛型编程您自己的代理/客户端层（请参阅类 客户群, ， 捆绑）。我发现这很容易开始工作，但很难做到完美。
  2. 使用第三方实现 1 (软件就是辛苦的工作 是我目前最喜欢的）

世界碳纤维 是所有早期的替代品 网络服务 来自微软的技术。它还比传统上被认为是“Web 服务”的功能要多得多。

WCF“Web 服务”是通过 WCF 实现的更广泛的远程通信的一部分。与通过传统的 ASMX 相比，您将在 WCF 中获得更高程度的灵活性和可移植性，因为 WCF 的设计从头开始，总结了 Microsoft 提供的所有不同的分布式编程基础结构。WCF 中的端点可以像通过 TCP/二进制一样轻松地通过 SOAP/XML 进行通信，并且只需配置一个配置文件 mod 即可更改此介质。理论上，这减少了移植或更改业务需求、目标等时所需的新代码量。

ASMX is older than WCF, and anything ASMX can do so can WCF (and more). 。基本上，您可以将 WCF 视为试图在 Microsoft 世界中逻辑地将所有不同的方式组合在一起，使两个应用程序进行通信；ASMX 只是众多方法中的一种，因此现在被归入 WCF 功能保护伞下。

Web 服务只能通过 HTTP 访问，并且在无状态环境中工作，WCF 非常灵活，因为它的服务可以托管在不同类型的应用程序中。托管 WCF 服务的常见方案有 IIS、WAS、自托管、托管 Windows 服务。

主要区别在于 Web 服务使用 XmlSerializer。但 WCF 使用 DataContractSerializer，与 XmlSerializer 相比，它的性能更好。

什么场景必须使用WCF

  • 处理业务交易的安全服务。一项服务
  • 向其他人提供当前数据，例如交通报告或其他
  • 监控服务。允许两个人聊天的聊天服务
  • 实时通信或交换数据。仪表板应用程序
  • 轮询一个或多个服务以获取数据并以逻辑方式呈现它
  • 推介会。公开使用 Windows Workflow 实现的工作流
  • Foundation 作为 WCF 服务。用于轮询的 Silverlight 应用程序
  • 最新数据源的服务。

WCF的特点

  • 服务导向
  • 互操作性
  • 多种消息模式
  • 服务元数据
  • 数据合约
  • 安全
  • 多种传输和编码
  • 可靠且排队的消息
  • 持久的信息
  • 交易
  • AJAX 和 REST 支持
  • 可扩展性

来源： 主要文本来源

微软软件定义网？我通常对图书馆参考本身做得很好，并且我通常希望在那里找到有价值的文章。

就它提供的功能而言，我认为答案是兼容性。ASMX 服务非常微软化。并不是说他们没有尝试与其他消费者兼容；而是说他们没有尝试与其他消费者兼容。但除了 ASP.NET 网页和其他一些定制的 Microsoft 用户之外，该模型的设计并不适合太多。而 WCF 因其架构而允许您的服务拥有基于非常开放标准的端点，例如REST、JSON 等除了通常的 SOAP 之外。其他人可能会比使用 ASMX 服务更轻松地使用您的 WCF 服务。

（这基本上都是通过比较MSDN阅读推断出来的，所以了解更多的人请随时纠正我。）

WCF 不应被视为 ASMX 的替代品。从它的定位以及微软内部如何使用它来看，它确实是一个用于任何类型的跨界通信的基础架构部分。

我相信 WCF 在很多方面确实推进了 ASMX Web 服务的实现。首先，它提供了一个非常好的分层对象模型，有助于隐藏分布式应用程序的内在复杂性。其次，您可以拥有的不仅仅是请求重播消息传递模式，包括从服务器到客户端的异步通知（纯 HTTP 不可能实现），第三，从 XML 消息传递中抽象出底层传输协议，从而优雅地支持 HTTP、HTTPS、TCP 等。与“第一代”Web 服务的向后兼容性也是一个优点。WCF 使用 XML 标准作为内部表示格式。这可以被视为优点或缺点，尤其是随着 JSON 等“XML 的无脂肪替代品”日益流行。

我发现 WCF 的困难在于管理客户端和服务器的配置，并对不太好的故障状态异常进行故障排除。

如果有人有任何捷径或技巧，那就太好了。

我发现那是一种痛苦；因为我在两端都有.NET，在两端加载了相同的“合同”dll，等等。但随后我必须处理很多细节，例如“KnownType”属性。

WCF 还默认只允许 1 或 2 个客户端连接到服务，直到您更改大量配置。从代码更改配置并不容易，传送大量 comfig 文件也不是一个选择，因为将我们的更改合并到客户在升级时可能所做的任何更改太难了（而且我们不希望客户使用 WCF 设置！）

.NET 远程处理在大多数情况下都可以正常工作。

我想尝试 假装 .NET 到 .NET 基于对象的通信与向未知系统发送文本 (xml) 位相同，这一步太过分了。

（我们有几次使用 WCF 与 Java 系统对话，我们发现 Java 系统给出的 XSD 与它想要的 XML 无论如何都不匹配，因此必须手动编写大量 XML 映射。）

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top