firemail

标题: Windows程序设计:MFC 、Winform 和 WPF 比较 [打印本页]

作者: Qter    时间: 2023-3-29 14:19
标题: Windows程序设计:MFC 、Winform 和 WPF 比较
[color=rgba(0, 0, 0, 0.75)]文章目录

MFC生成本机代码,自然是很快,可是消息循环减缓了界面显示速度。

WinForm封装了win32的api,多次进行P/invoke操作(大部分使用p/invoke操作封装),速度慢。

WPF是一种新的模型,不再使用win32模型,自己新建模型,使用dx作为新的显示技术,直接访问驱动程序,加快了运行速度,可是,这种模型,需要支持dx9的显卡,硬件要求高(你还能找到现代机器不支持dx9的吗?)

开发效率上,MFC < WPF < WinForm

尽管MFC开发界面执行效率高但是开发效率低,作为现在的项目开发来说时间跟开发效率往往能决定项目的成败,所以除非有特别的需求,否则都会尽量避免用MFC来做开发,MFC只是一个弱封装器。

开发成本,MFC > WPF > WinForm

用MFC开发成本太高,对开发者能力要求更高,作为客服当然希望开发的费用越少越好,开发者当然希望钱赚得越多越好,这样一比,这也是MFC没落的一个很大的原因。

界面执行效率上,MFC == WPF > WinForm

随着计算机硬件的性能提高,多核cpu的普及,它们的差距会越来越小。

开发灵活性上:WPF > MFC > WinForm美观上:WPF > WinForm > MFC

这一项中MFC下要开发出一个华丽的ui极其困难,也许你可以说你可以用控件,但是商业开发控件是要收费的!!MFC要写出这种效果不知要写到何年何月。这样一来MFC存在的价值就更低了。效率和美观不如WPF,开发效率又不如WinForm。

内存使用上:WPF > WinForm > MFC

随着计算机硬件的性能提高WPF这个缺点会被忽略。

使用范围:WPF > MFC == WinForm

有以上可知:WPF大有取代WinForm和MFC之势,从未来net的发展来看,MFC以后只会变成一种经典,作为一种技术来供开发者学习,WinForm和WPF两者会并存发展,但最终都会被WPF取代,最终实现桌面应用程序和浏览器应用程序的统一。


https://blog.csdn.net/sinat_40003796/article/details/125767203



作者: Qter    时间: 2023-3-29 14:20
作者:ifdog
链接:https://www.zhihu.com/question/55901875/answer/196147071
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

P/Invoke又名平台调用,是.NET CLR提供的,为了使开发者从托管代码(如题主的C#)调用动态连接库中的非托管代码(通常是C)而提供的一种服务。类似的功能,JAVA中叫JNI,Python中叫Ctypes。
因为不同语言,不同开发环境的数据类型、结构都是不同的,当你使用P/Invoke调用dll的时候,平台会自动给你加载这个dll,并且在托管代码和非托管代码的边界自动完成数据类型转换。
使用P/Invoke的话,一般分为3步:声明,调用,异常处理。
举例,在user32.dll里有一个如下签名的函数:
BOOL SetCursorPos(int X,int Y)
我们在C#中声明
[DllImportAttribute("user32.dll", EntryPoint = "SetCursorPos")][return: MarshalAsAttribute(UnmanagedType.Bool)]public static extern bool SetCursorPos(int x, int y);
然后调用(没错我是大括号换行党)
static void Main(string[] args)        {                SetCursorPos(250, 250);        }
参考资料:Platform Invoke Tutorial
然后如果要做异常处理,可以参考这篇:送专利啦~~ .Net高阶异常处理之TopLevelEH

https://www.zhihu.com/question/55901875








欢迎光临 firemail (http://firemail.wang:8088/) Powered by Discuz! X3