[TSG开发日志3]从C#到Qt，再从Qt到C#，浅谈不同技术之间选型的利与弊

当前在South公司的开发历经了几个时代，第一个时代是用C#进行的开发，第二个时代是从C#向Qt逐渐转型，第三个时代是我现在站在十字路口上，又需要将采集端软件从Qt的路上拉回来。

为什么

先看看AI怎么说

选择使用C#还是Qt来进行设备控制的上位机开发，取决于多个因素。下面我将详细讨论每个方面以及两种技术的优势和特点：

语言特性和生态系统: C#是一种现代的面向对象编程语言，拥有丰富的特性和强大的生态系统。它是Microsoft的主要开发语言之一，并且在Windows平台被广泛使用。C#具有简洁的语法、强大的标准库和活跃的开发社区，这可以帮助你快速开发应用程序并解决问题。此外，C#还有一些用于设备控制和通信的特定库，如.NET SerialPort类和第三方库（例如Modbus库）。
Qt是一个跨平台的应用程序开发框架，使用C++编写。它提供了丰富的功能和模块，包括图形界面、网络通信、数据库访问等等。Qt拥有广泛的跨平台支持，可以在Windows、Mac、Linux等多个操作系统上运行。此外，Qt具有信号和槽机制、自动内存管理、良好的国际化和本地化支持等特性，使开发变得更加方便。

结论：如果你的设备控制应用程序主要是在Windows平台上运行，并且你已经熟悉C#和相关技术生态系统，那么选择C#可能会更加适合。如果你需要跨平台支持，或者对C++和Qt有很好的熟悉度，并且希望获得强大的图形界面和其他功能模块，那么选择Qt会是一个不错的选择。
图形界面开发: C#和Qt都提供了图形界面开发的功能。C#使用Windows Presentation Foundation (WPF)和Windows Forms来创建丰富、交互式的用户界面。WPF使用XAML来定义界面，提供了强大的数据绑定、样式和动画特性。Windows Forms则是更传统的Win32窗体应用程序开发方式，易于上手和使用。

Qt提供了一套成熟的图形界面开发框架，使用Qt Widgets或Qt Quick，可以创建各种各样的界面。Qt Widgets是基于传统的Widget和Layout的方式，易于掌握和定制。Qt Quick则使用基于QML的语言，提供了更现代和声明式的方式来构建界面。

结论：如果你希望使用现代化的图形界面技术，并且以Windows平台为主，C#和WPF可能更适合你。如果你需要跨平台支持或者对Qt的图形界面开发有更多的了解，那么选择Qt会是一个不错的选择。
性能和资源使用: C#以及相关的.NET框架在性能方面表现良好，并且拥有优秀的垃圾回收机制。如果你的设备控制应用程序需要处理大量数据、实时控制或者对性能有较高要求，使用C#可能会更合适。

Qt使用C++编写，底层性能较高，且具有较低的资源消耗。如果你的应用程序对性能和资源使用有严格的要求，或者需要对底层进行优化，Qt可能会是更好的选择。

结论：如果你对性能和资源消耗有较高要求，或者需要进行底层优化，Qt可能会更适合你。如果你对性能要求较低或者使用相关的优化技术（如并行处理和异步编程），那么C#也可以满足大多数需求。

为什么我突然会想到要使用C#进行采集端软件开发，其实主要是基于C#的几个优点：

C#本身是内存安全的语言，可以不管你怎么写，反正代码总是可以按照既定的路线往下走。就是什么意思呢，只要一个try catch包住你的代码字段，不管怎么样代码总是能走下去的。C#在流程安全上相比于Qt有绝对得天独厚的条件，可以在作业流程完全跑通的前提下，无视任何分支函数的错误。可以无视内存级别的错误，越界啊，什么的。
C#的开发效率相对较高，而且对网页网络等有更好的优化。这一点也是非常关键的。我们在下一步的开发中即将绑定大量的网页网络内容，甚至有可能让整个软件架构直接建立在网页上。另外因为C#的语法简单，而且可维护性相当高，所以即使后续招过来的开发人员水平参差不齐，依旧不会把这个项目做烂。
C#跨平台的优势。C# 现在在.NetCore上的跨平台我个人感觉支持比Qt好一点，虽然不论怎么说也是微软的亲生儿子，但既然这一次都把.NetCore整个公开了源码且高调支持了跨平台，那肯定是可以相信的，毕竟有微软这么个顶级大公司背书，怎么也不会比Qt这种公司差的。
代码好维护。C#的代码虽然可能短时间看不懂，但其语法总的来说还是非常简单的，不管你怎么维护，在Try Catch这么高的包容度下基本上不可能写烂，后面来接手项目的人不管代码写的有多垃圾，都是可以维护的下去的。
C#也可以直接调用C++的DLL，虽然过程曲折了一点，但目前我已经大概搞清楚怎么做了。

总而言之，建立在现在.net生态如此强大的前提下，我认为.net是相比起Qt更加强大的平台