闲话 .NET(7):.NET Core 能淘汰 .NET FrameWork 吗?

简介: 闲话 .NET(7):.NET Core 能淘汰 .NET FrameWork 吗?

前言

虽然说,目前 .NET FrameWork 上的大部分类都已经移植到 .NET Core 上,而且 .NET FrameWork 也已经停止了更新,未来必然是 .NET Core 的天下,但要说现在 .NET Core 就能淘汰 .NET FrameWork,我觉得为时尚早,因为 .NET FrameWork 的一些独有特点,有些技术暂时无法或很难在 .NET Core 上实现,比如本文提到的这些技术。

.NET FrameWork 的独有技术

WinForms、WPF 这两项技术和 Windows 操作系统深度耦合,很难被迁移到其他操作系统下,所以 .NET Core 上虽然也可以开发 WinForms、WPF 程序,但开发出来的程序依然只能运行在 Windows 操作系统里,不能跨平台地运行在 Linux、macOS 等操作系统里,而且,有些 .NET FrameWork 上 WinForms、WPF 有的类,在 .NET Core 上并没有,比如串口通信控件 SerialPort。当然,在 .NET Core 上开发 WinForms、WPF 程序,可以利用 .NET Core 的独立部署、模块化、更高性能等特性,这些是在 .NET Framework 下进行WinForms、WPF开发所不具备的。

由于历史原因,还有相当部分网站是使用 ASP.NET WebForms 技术开发的,但 ASP.NET WebForms 已经过时,所以并没有移植到 .NET Core 上,如果要维护这些网站,必须使用 .NET Framework。

3. WCF(Windows communication foundation,Windows 通信基础)

WCF 的优势在于支持多种通信协议和强大的消息处理能力,但配置起来非常复杂,不符合框架设计的KISS(keep it simple and stupid,保持简单和傻瓜化)原则,所以也并不 .NET Core 支持,如果要使用 WCF 也必须在 .NET Framework 下或者使用第三方开源技术比如 CoreWCF。

鉴于 WCF 太复杂,有个建议,如果仅是进行网络通信,可以使用 ASP.NET Core Web API、gRPC 等技术代替,如果想要使开发出来的系统具备有序消息、队列服务、分布式事务、限流等高级特性,可以选用有对应功能的开源组件,不必使用 WCF 这样复杂的集成框架。

4. WF(Workflow foundation,工作流框架)

WF 是一个用于构建工作流应用程序的框架,它提供了一种可视化的方式来设计和执行工作流程,但 WF 是一个特定于 Windows 操作系统的功能,不太适合跨平台,而且 .NET Core 更加关注于现代化的开发模式和技术,如微服务架构、云原生应用等,WF 并不是其主要的开发重点,所以 .NET Core 并不支持 WF,如果有业务需要只能在 .NET Framework 下应用或者寻求第三方开源技术。

5. .NET Remoting

.NET Remoting 用的是微软的私有协议,性能也不咋的,使用并不是很广泛,所以 .NET Core 也不支持 .NET Remoting,代之以谷歌开源的 gRPC,如果要使用 .NET Remoting 必须回到 .NET Framework

6. AppDomain(应用程序域)

AppDomain 是 .NET Framework 提供的一种隔离和管理托管代码执行环境的机制。每个应用程序在运行时都会有一个或多个 AppDomain,每个 AppDomain 都有自己的应用程序配置信息、安全策略、代码库等,可以独立加载和卸载程序集,提供了一种隔离和安全性的机制。应该说,微软的这个想法是很好的,无奈现实太骨感,在实际使用中,AppDomain 技术暴露出有很多缺陷和局限性,所以它并没有被移植到 .NET Core 上,是 .NET Framework 独有的技术。

7. 其他

其他还有如 WMI(Windows management instrumentation,Windows管理规范)、ODBC(open database connectivity,开放式数据库互连)、Windows ACL(access control list,访问控制列表)、Code Page、Windows事件日志、Windows性能计数器、Windows注册表、Directory Services 等技术,这些技术是 Windows 特有的技术,在其他操作系统下没有对等的实现,所以也是 .NET Framework 独有的技术。

结语

.NET Core 相对 .NET Framework 而言是无法向前兼容的破坏性创新,这样做的好处是 .NET Core 可以抛开历史包袱做出突破性创新,但这样也意味着 .NET Framework 中的少数功能无法或很难被 .NET Core 支持,所以 .NET Core 暂时还不能全面取代 .NET Framework,希望在未来的版本中,.NET Core 能够给出更好的解决方案。

您还知道 .NET FrameWork 中哪些技术没有被迁移到 .NET Core 吗?欢迎留言讨论。

我是老杨,一个奋斗在一线的资深研发老鸟,让我们一起聊聊技术,聊聊人生。

都看到这了,求个点赞、关注、在看三连呗,感谢支持。


相关文章
|
2天前
|
Java 物联网 C#
C#/.NET/.NET Core学习路线集合,学习不迷路!
C#/.NET/.NET Core学习路线集合,学习不迷路!
|
5天前
|
Java 物联网 编译器
C#一分钟浅谈:.NET Core 与 .NET 5 区别
本文对比了 .NET Core 和 .NET 5,从历史背景、主要区别、常见问题及易错点等方面进行了详细分析。.NET Core 侧重跨平台支持和高性能,而 .NET 5 在此基础上统一了 .NET 生态系统,增加了更多新特性和优化。开发者可根据具体需求选择合适的版本。
22 7
|
2天前
|
人工智能 开发框架 前端开发
C#/.NET/.NET Core技术前沿周刊 | 第 12 期(2024年11.01-11.10)
C#/.NET/.NET Core技术前沿周刊 | 第 12 期(2024年11.01-11.10)
|
2天前
|
开发框架 网络协议 .NET
C#/.NET/.NET Core优秀项目和框架2024年10月简报
C#/.NET/.NET Core优秀项目和框架2024年10月简报
|
1天前
|
人工智能 开发框架 安全
C#/.NET/.NET Core技术前沿周刊 | 第 13 期(2024年11.11-11.17)
C#/.NET/.NET Core技术前沿周刊 | 第 13 期(2024年11.11-11.17)
|
25天前
|
开发框架 缓存 监控
NET Framework 到 .NET 5/6 的迁移是重大的升级
本文详细介绍了从 .NET Framework 4.8 迁移到 .NET 5/6 的过程,通过具体案例分析了迁移策略与最佳实践,包括技术栈评估、代码迁移、依赖项更新及数据库访问层的调整,强调了分阶段迁移、保持代码可维护性及性能监控的重要性。
46 3
|
1月前
|
人工智能 开发框架 Cloud Native
C#/.NET/.NET Core技术前沿周刊 | 第 9 期(2024年10.07-10.13)
C#/.NET/.NET Core技术前沿周刊 | 第 9 期(2024年10.07-10.13)
|
1月前
|
开发框架 前端开发 API
C#/.NET/.NET Core优秀项目和框架2024年9月简报
C#/.NET/.NET Core优秀项目和框架2024年9月简报
|
1月前
|
开发框架 NoSQL MongoDB
C#/.NET/.NET Core开发实战教程集合
C#/.NET/.NET Core开发实战教程集合
|
1月前
|
数据可视化 NoSQL C#
C#/.NET/.NET Core技术前沿周刊 | 第 8 期(2024年10.01-10.06)
C#/.NET/.NET Core技术前沿周刊 | 第 8 期(2024年10.01-10.06)

热门文章

最新文章