写点什么

服务器端 WCF 开发计划不明,开发者表示遗憾

  • 2019-06-14
  • 本文字数:1885 字

    阅读完需:约 6 分钟

服务器端 WCF 开发计划不明,开发者表示遗憾

微软在与服务器端 WCF 相关的问题上仍然没有什么进展。在人们看来,服务器端 WCF 似乎已经是一项过时的技术。微软的一名员工表示,这需要点耐心,这与之前的声明并不矛盾。


虽然客户端 WCF 从一开始就可用,但多年来微软一直拒绝将WCF的服务器端移植到.NET Core。除了团队规模问题之外,从来没有人解释为什么没有将它们看成一个整体看待。源代码可以在Reference Source上找到,而且大多数绑定都是跨平台的。


注意,有一些安全选项和绑定只针对 Windows 的(例如命名管道、MSMQ),不过Windows Compatibility Pack已经为其他库解决了这些问题。


在 Scott Hunter 给出如下的描述后,引起了用户新一轮的抱怨:


在.NET Core 3.0 之后,我们将不再从.NET Framework 中移植任何功能。如果你是一个 Web Forms 开发人员,并且希望基于.NET Core 构建一个新的应用程序,我们将推荐使用 Blazor,它提供了最接近的编程模型。如果你是一个 Remoting 或 WCF Server 开发人员,并且希望基于.NET Core 构建一个新的应用程序,我们建议使用ASP.NET Core Web API 或 gRPC,它们提供基于跨平台和跨编程语言的 RPC。如果你是一个 Windows Workflow 开发人员,可以使用开源的 Workflow .NET Core 移植版本。


这让很多.NET 开发人员感到不安,他们一直认为 REST 不能替代 WCF。gRPC 也是一样,从 WCF 用户的角度来看,gRPC 只不过是一个忽略了 WCF 提供的其他功能的绑定。简单地说,它们都没有发挥抽象通信框架的作用,而这正是 WCF 的主要意图。(更不用说因为一些遗留问题和合约原因需要支持 WS-*/SOAP 了)。


GitHub 用户 dgxhubbard 写道:


Scott 的声明说了一件事:“使用 gRPC 愉快!”我希望做出这个决定的人也能使用 gRPC 来编写代码,并替换掉一些 WCF 服务器服务,看看这句话到底意味着什么。我们将不得不重写我们的服务来模拟 WCF,所以我们对.NET Core 3 和更高版本的采用将被搁置一段时间。


Chris Benard 表示赞同:


我表示赞同。我不认为 gRPC 会是一个很好的替代方案。WCF 最大的卖点之一是能够在服务器端和客户端之间共享 DLL,提供了丰富的服务契约模型和接口。在我看来,gRPC 依赖于代理生成。我们的一些服务会保存序列化对象的副本,以便稍后重用它们,我不知道 gRPC 将如何实现这些。

我真的不想再手动使用 NetDataContractSerializer,然后把字节强制放到 gRPC 管道或其他什么东西上(.NET Core 中有 NetDataContractSerializer 吗?我希望或者假设是不存的,但 DataContractSerializer 存在)。

合约对我来说不是什么大事,它是具有相同 DLL 的服务器/客户端之间的模型共享。

此外,还有需要在单个 ServiceHost 上提供多个端点的能力。我们可以在一个端点上具有 TransportSecurity,在另一个端点上具有 MessageSecurity。我们用它来更新端点上的安全性,但 gRPC 似乎都不支持这些。

更不用说我们的用户必须一个接一个地打开出向端口,而且我们不能只使用 gRPC 将同一个端口迁移到集群。

这一切都意味着.NET Core 在很长一段时间内都无法在服务器端使用。感谢上帝,我从未在客户端使用过 WS-Security 或其他任何东西,所以我没有掉进这个坑。但是,我必须重新定义 netstandard2.0 共享的服务器端 DLL,然后尝试了解核心 WCF 客户端和 WCF 服务器之间的工作原理。

这真是一个噩梦,我几乎失去了整个框架。

gRPC 甚至不支持用于本地跨进程远程的命名管道,而这在 WCF 中我认为是理所当然的事情…


微软的 Matt Connew 发表了几条评论,暗示了 WCF 用户的未来之路:


Scott 的这句话并不是在讨论 WCF 代码库,因为 WCF 现在与.NET 是分开的,它更像是一个外部库,而不是框架的一部分。虽然目前我还不能对服务器端 WCF 做任何特别的说明,但是将更多的 WCF 特性移植到服务器的可能性还是有的,我们确实希望支持更多的场景。


Matt 最近重申:


我保证,在 Build 大会之后,会有大量的意见被听取,请再耐心一点。大型企业的轮子有时可能又大又重,需要很大的力气才能转动它们,而且可能会移动得很慢。Scott Hunter 在 Build 大会上布有一些东西正在开发中,而且确实如此。


然而,微软的 Stephen Bonikowsky 似乎提出了反驳观点:


在 WCF 服务器端方面,并没有计划将其包含在代码库中。不过,人们对服务器端非常感兴趣,你可以关注 #2695 中正在进行的讨论,特别是 @mconnew 最近在那里发表的评论。


这可能意味着这是一个从服务器端 WCF 单独代码库到整体的重新设计,就像我们在使用 Entity Framework 替换 LINQ-to-SQL 时看到的那样。现在还说不清楚,而且微软还没有准备好公布他们的计划。


查看英文原文Unclear Plans for Server-Side WCF Continues to Frustrate .NET Developers


2019-06-14 08:009135
用户头像

发布了 731 篇内容, 共 460.1 次阅读, 收获喜欢 2004 次。

关注

评论

发布
暂无评论
发现更多内容

开源时代:极狐GitLab如何保证软件供应链安全

极狐GitLab

一起学Elasticsearch系列-深度分页问题

Java随想录

Java 大数据 elastic

人工智能可以战胜人类智慧大脑么?

天津汇柏科技有限公司

人工智能

终端闲思录(2)- 终端的源流嬗变

蓬蒿

终端 终端仿真

Java第一个程序——Hello,World!

小魏写代码

软件开发

Geek_8da502

[译]优秀的URL设计

南城FE

前端 后端 url

Wi-Fi 6 vs. Wi-Fi 6E: The differences between IPQ6018, IPQ6010 and IPQ5018

wallysSK

顶级加密混淆混淆工具测评:ipagurd

支付宝 v3 自签名如何实现

盐焗代码虾

Java 支付宝 签名 加签

强大的数据库管理:Valentina Studio Pro终端激活版最新

胖墩儿不胖y

Mac软件 数据库软件 Mac管理数据库

唯品会商品列表数据接口(Vip.item_search)丨唯品会API接口

tbapi

唯品会商品列表数据接口 关键词搜索唯品会接口 唯品会API接口 唯品会商品数据接口 唯品会商品API接口

使用 Taro 开发鸿蒙原生应用 —— 探秘适配鸿蒙 ArkTS 的工作原理 | 京东云技术团队

京东科技开发者

现代 CPU 技术发展 | 京东云技术团队

京东科技开发者

软件开发 cpu 性能提升

用JS实现简单的屏幕录像机 | 京东云技术团队

京东科技开发者

JavaScript 前端 屏幕录制

同事突然问我:异步网络请求编码的方法

华为云开发者联盟

开发 华为云 华为云开发者联盟

数据库编程大赛:一条SQL计算扑克牌24点

NineData

数据库 sql SQL开发 NineData 编程大赛

即时通讯技术文集(第28期):IM开发技术合集(Part1) [共18篇]

JackJiang

网络编程 即时通讯 IM

centos 7.6安装sealos和单机集群

麦兜

杭州悦数成立「悦数图技术陆家嘴数据智能研究院」,入驻上海陆家嘴金融城「双城辉映」平台

最新动态

高级数据库数据安全保障方法就是使用靠谱的工具!

行云管家

数据库 数字化 数据安全 数据安全运维

#issue 111538 MySQL 8.0 instant add/drop column 性能回退问题

ba0tiao

MySQL InnoDB

强烈推荐的前端学习资源,先收藏!

伤感汤姆布利柏

前端 工具

vivo 容器平台资源运营实践

vivo互联网技术

容器平台 资源运营 利用率提升

TDengine 创始人陶建辉出席 CIAS 2023 年会,为新能源汽车数据处理带来新思路

TDengine

tdengine 时序数据库

拆解低代码平台核心功能:八大关键点解析

天津汇柏科技有限公司

低代码

HarmonyOS应用事件打点开发指导

HarmonyOS开发者

HarmonyOS

服务器端 WCF 开发计划不明,开发者表示遗憾_语言 & 开发_Jonathan Allen_InfoQ精选文章