对于DevExpress Library总想写些什么的，可是总是觉得自己学的东西还不足以写出点好东西来，所以，这一个月就是不停的学习和了解这个库，可是什么也没有学通，也不敢轻言写些什么了。然而一个多月了，一方面对它的源代码也看了一些了，大概是1%-3%左右吧(了解的少得可怜)；另一方面是用它的一些框架也做了一些东西，所以还是习惯的想写些与此相关的东西。
这个库做的很臃肿，一方面是它是很老的一个框架了，对于.Net来说应该时，因为.Net发展的时间也就只有五六年的时间，而这个库的也就是与.Net一起成长的，因此里面有很多老的结构与功能。首选就是类的升级与扩展，很多类先是 XXClass，然后又出现了XXClassEx，显然是一个升级。而又会有一个XXClassEx2，呵呵，二次升级。这样的内容在这个库中很多，特别是一些基础框架库里的，主要就是DevExpress.Data和DevExpress.Utils两个库里。其次就是一些逻辑结构的调整，这主要表现在一些名字空间中类的代码所在的位置。因为这是一个商业库，而且并不是一个统一的整体，很多功能它是独立出售的，因此在代码组织上存在一些与设计模式相违背的情况。例如它的PrintingSystem，是一个独立的模块，用户可以只购买这一个模块，而不用购买其它的如Report的模块。然而，PrintingSystem是一个完整的系统，报表要打印就必须要使用PrintingSystem，对于没有购买PrintingSystem的用户来说，Report还是要能正确运行的，那么它与PrintingSystem之间的通信如何解决呢？这个库全部采用了字符串以及一些基础接口。正确合理的做法应该是采用统一的ID或者枚举等一些高效的做法。而接口在它里面使用的也很别扭，例如，一个接口有一个方法要返回SomeObject类型，然后SomeClass实现了这个接口，返回了SomeObject类型。然而，后期扩展上出现了SomeClass的派生类，要实现这个接口而且返回类型要求是SomeObject的派生类，也就是说，要求派生类返回派生类型。这一个矛盾的问题，在这个库里的实现也是很别扭的，它是采用了覆盖父类的方法，重新返回新的类型，但还是调用父类的方法。代码大概就是：
new SomeNewObject SomeProperty{
get{return base. SomeProperty as SomeNewObject;}
}
首先类型转化就是最大的系统开销（查阅一下MS对.Net性能开销的测试就知道了），其次在代码管理上就存在一些容易混淆的理解，如果不是在运行时跟踪，单是看源代码，你是很难知道它到底执行了哪段代码，这一点我是深有体会，而且感觉很郁闷的事情。
另一个臃肿的地方就是在skin的维护上，整个框架的一个大头就是skin，而且它还提供了工具来自己开发skin。自己开发的skin是如何在运行时应用的呢？唯一解决方法就是反射。在skin上存在大量的反射，在源代码上基本上找不到关于skin的信息，大部份都是在运行时通过反射解决。这是它系统臃肿，性能低下的一个主要问题。关于skin这一块我还没有仔细研究过，可能比我目前了解的要好，也可能更糟糕。
最后一个臃肿的地方就是新老模块的整合问题，存在一些废弃的代码是必然。.Net本身也有这样的问题，但它废弃的不是简单的个别类或者个别方法，而是一些大的逻辑结构。例如，DevExpress.Data中一些数据库访问，就完全被后来的DevExpress.XPO模块所完全取代。而Data中的大部份功能还是保留，这样就是一个大的重复。XPO大概是在6.0以后才添加进来的，可以想象得到，里面的重复还是很多的。
好了，先总结这些，其实也没什么太大的意义，一方面是觉得自己应该写点什么，另一方面也是想keep这个习惯。整体而言，这个框架还有很多要改进的地方，DevExpress也在努力的改进（我在源代码中看到了一些关于windows vista的版本控制代码，让我感觉有点吃惊，因为我的这个版本还算是比较早的，应该不足以考虑vista的问题，但DevExpress还是有这方面的想法），另一方面，这个框架也是很值得学习的实例。对于使用而言，如果不考虑性能问题，它还算是一个非常不错的控件库，控件很全面，功能也很强大。至于性能问题，如果是放心的交给硬件的话，就什么都不说了。呵呵。。。。