很不明白微软为什么不改进MFC或者开发一个替代产品。。。
tczyp 2006-04-18 11:03:54 虽然说,。net相对于MFC有如下优势:
提供一个一致的面向对象的编程环境,而无论对象代码是在本地存储和执行,还是在本地执行但在 Internet 上分布,或者是在远程执行的。
提供一个将软件部署和版本控制冲突最小化的代码执行环境。
提供一个保证代码(包括由未知的或不完全受信任的第三方创建的代码)安全执行的代码执行环境。
提供一个可消除脚本环境或解释环境的性能问题的代码执行环境。
使开发人员的经验在面对类型大不相同的应用程序(如基于 Windows 的应用程序和基于 Web 的应用程序)时保持一致。
它提供全新的类库,并以命名空间分类,提供新的form(窗体)编程和更丰富的控件,更接近快速开发的要求并不失去它的灵活性,对系统底层的访问可以通过system.windows空间实现。
还有就是垃圾收集机制大大方便了开发者,多种语言之间取长补短。
尽管如此,我认为从本质上来说,。net尽管神通广大,但也对于windows平台上面的效率要求比较高的程序不应该是。net的势力范围。
我觉得有下面几个原因:
1,就windows平台开发而言不存在跨平台的需要。所以GIT(二次编译)是完全没必要的。
2,对C++的支持是非常必要的,据我所知很多大型软件都提供MFC的接口,比如matlab,实质上他们提供的是C++的接口,如果不能很好的支持C++的话(我目前认为C++、Cli并不算非常地道地支持C++)那么那些对效率要求很高的数值计算函数的速度将会变成怎样将是一个未知之数。
3,如果要用。net来代替mfc的话,那么这些大型软件本身是不是也要用。net来开发?比如像matlab,photoshop,office(看上去这些软件是用mfc开发的。)那么是不是要他们从头开始用。net来写一次?
4,。net所具有的一些优势其实也可以用到mfc上面,比如快捷的开发方式,比如可以通过改良MFC的IDE,同时添加一些控件使到程序员拥有更多预先装配好的模块。
也许我想说的并不针对mfc或者。net,而是想说,。net不是为纯windows软件而度身量做的,尽管它很强大,但是它不可能面面具到。对于开发纯windows程序,我觉得现时的。net某些方面多余了,而另外又有些方面不足。如果mfc淘汰了,那么是否应该有一个为开发纯windows程序而度身量做的来填补mfc的空白?(当然它也可以是。net的一份子,不过应该不是目前的C#或者VB.net)