上一篇文章主要讲了一下我当时写的一个ORM工具，其实我为啥要自己写一个ORM工具，其主要核心在于为了动态生成一些业务和界面。而当时应该有比较多的ORM开源项目，他们的特点都是需要设计时建立一个实体类与数据库的数据对象对应。而一般的平台都需要的是运行时产生实体类与数据库对象对应，这样数据库对象有变化后，在程序运行时都能动态感知。目前的Linq、XPO、Hibernate等如果要运行时支持的话，估计都要花不小的力气去改造，而且不见得效果能非常好。而我的ORM采用的是DataRow和DataTable作为实体对象和实体集合。严格来讲，我这个ORM是一个伪的ORM，不像大多数的工具，我只是对DataTable和DataSet进行了封装，以便于能自适应进行数据新增、删除、修改、保存、校验以及在保存前的一些数据准备和保存后数据的处理等功能。这个有点类似于其他实体类需要处理的工作，总之我的ORM一切围绕着DataRow、DataTable、DataSet进行展开，处理一切逻辑业务数据的处理。如数据推送到界面后，界面与逻辑业务交互的数据处理，就放置在界面层处理。
在这篇文章里面，我还想介绍下我的平台所使用的Devexpress控件，各位可以看看我写的一篇文章《说说我使用的第三方控件Devexpress 》，里面主要是介绍我对Devexpress的一些认识。为什么这里还会提到呢？是因为我平台上界面展示的控件都是用Devexpress控件，几乎没有用.Net自己的控件。而无论你使用的是第三方控件还是.Net自带的控件，都存在你如何去改造控件，来适应业务逻辑展示的需要。对于.Net自带的控件的改造，都是基于你自己的源码去改造，肯定在.Net升级上没有太大问题，如果出现不兼容，从你自己的代码上进行理解和改造也是轻车熟路的过程。而如果你把第三方控件也采用这样的方式进行改造的话，就会存在对将来版本不兼容得情况，而且要修改的幅度非常大。以Devexpress为例，从05年后，都是以年份为大版本，每年2~3个主版本升级，每月小版本升级；主版本的升级都会带来一些功能的废弃和一些功能属性方法带来的Break Change，如果你使用源码进行改造的话，是很难去适应新版本。而第三方控件的升级改造、新功能添加每年都会有比较大的改进，因为他们改进和优化的想法都是来自客户要求增加功能评论次最多的。我想这些需求也是我们想要的。所以我在我平台中对第三方控件采取的方式就是：继承反射化改造第三方控件，而不是采取修改代码，如下图所示：
这样的好处，前面已经说过了。我所有跟界面有关的控件，不涉及业务封装的，都放在WinGUI类库中，这个是不依赖ORM的。后一篇文章我会说到我在原始构想的平台上对于一些通用业务处理的模块，等把我在05年那个时候的构想都说完后，会完整介绍下我目前的平台情况。
写博文真是一件体力活，我争取每周能写个3篇以上吧，如果大家想了解什么可以多关注我的博客，如果更新不是很及时，如果你也写自己的平台，可以跟我私下交流下，如有考虑不周，请大家见谅了。