【问题标题】:Current WCF technology alternatives for .NET-to-.NET services?.NET 到 .NET 服务的当前 WCF 技术替代方案?
【发布时间】:2009-12-30 23:08:40
【问题描述】:

我正在拆分 N 层堆栈,以允许独立扩展各层、更好地部署独立性,并且我想知道人们目前为服务边界通信技术选择了什么。

服务本身和服务的所有“客户端”都可以通过内部网络相互访问,并且目前都是 .NET 3.5 SP1(Windows 服务 3.5、ASP.NET MVC 1.0、ASP.NET WebForm 3.5 )。

我倾向于 Windows Communication Foundation,尽管我听说 WCF 在不久的将来会改变方向。这些谣言有道理吗?

我已经摒弃了构建为自定义 ASP.NET MVC 服务和旧式 SOAP Web 服务的想法,因为 WCF 将以自定义响应的能力为代价提供更灵活的传输选择。

真的有任何其他 .NET 服务技术需要考虑吗?


感谢大家的意见。很高兴听到我对 WCF 的倾向仍然是正确的选择,并且会持续一段时间。

【问题讨论】:

    标签: .net wcf service communication n-tier-architecture


    【解决方案1】:

    我没有听说过关于 WCF 改变方向的任何消息。

    我还要说这是您正在寻找的答案。您有大量的绑定选项可以工作并提供不同程度的性能。

    您可以在此处查看 WCF 和旧服务技术之间的性能比较:

    http://msdn.microsoft.com/en-us/library/bb310550.aspx

    【讨论】:

      【解决方案2】:

      WCF 可能是您的最佳选择。 WCF 在 .NET 4 中没有发生显着变化,因此迁移应该非常严格。

      (也许您正在考虑 Windows Workflow Foundation,它在 .NET 4 中几乎完全重写,并导致严重的迁移问题......)

      话虽如此,您还有其他选择 - 您可以使用 System.Net 命名空间编写自己的网络层。这只需要更多的工作,因为您基本上复制了 WCF 免费提供的大部分好处。

      【讨论】:

        【解决方案3】:

        目前,WCF 仍然是 .NET 服务之间的通信 API 最明显的选择。

        【讨论】:

          【解决方案4】:

          .NET 通信中的任何“新方向”都可能建立在可扩展性极强的 WCF 平台上。 WCF 是您应该为此考虑的唯一技术堆栈。

          【讨论】:

            猜你喜欢
            • 1970-01-01
            • 2011-06-27
            • 1970-01-01
            • 2011-08-18
            • 2014-02-11
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 2021-06-26
            相关资源
            最近更新 更多