对DirectUI的认识

几乎90%介绍DirectUI的人,都抓不住重点:像界面和逻辑分开、用XML来配置界面,都和DirectUI没有半点关系。
具体来说:只要界面是用文件来配置,都是界面和逻辑分开,VC的用的是*.rc文件,WPF用的是*.xaml文件、LibUIDK用的是*.ui文件。难道VC的对话框程序就不是界面和逻辑分开吗?难道必须用xml文件吗?
DirectUI仅仅是又实现了一遍微软已经成熟的控件,这样做有个好处:不受制于微软相关控件的约束。比如要做一个List控件,它的某些Item也需要用List来表达。如果是用CListCtrl,那么有两种办法:在CListCtrl中再创建几个CListCtrl,用来表示Item。但这有些弊端:一个窗口内子窗口的数量有限、使CListCtrl过于庞大,影响性能。还有一种方法就是,自己写一个类似于List的东东,来当作Item。这个实现上就有点接近DirecutUI了。如果自己写的这个List不但可以作为Item,还可以作为父控件,那它就是一个DirecutUI的控件了。
由于不受限于微软的很多约束,所以自由发挥的余地比较大。但发挥到什么程序,还要看各厂家的实力。所以不是说用DirectUI就一定可以开发QQ、MSN类似的界面,也不是说不用DirectUI就不能开发这样的界面。它们也是没有任何关系的。
当然,什么东东都是有利有弊的。当你抛弃微软,自己开发控件时,有多大的机率能比微软开发的强?有微软的稳定?有微软的兼容性好?还有一个问题是:由于这些控件都是各厂家自己开发的,那么原来mfc程序员需要对这些新的控件进行重新学习。有多少人愿意学习一种不通用的技术?
DirectUI还有一个好处:让自己的界面变得不标准。这要带来的直接好处是:增加Hack成本。比如想截获QQ的密码,如果是标准程序,正常情况下,把一个dll注入到QQ进程,然后拿到Edit的窗口句柄,就可以得到*号密码。现在用了DirectUI的edit,那么就没有句柄,也不支持标准CEdit的接口,就不能通过常规方法得到密码。让界面变得不标准,也是有利有弊的。如果自己的软件,希望第三方厂家为自己开发插件,那就最好不要用DirectUI。

你可能感兴趣的:(对DirectUI的认识)