AppFramework通用数据库访问组件之来龙去脉

 

 

一、起因

AppFramework，名字起得是有点大 。我的原始目标是做个全面的企业应用程序框架，内容涵盖B/S、C/S结构，从UI到DA，其功能应该覆盖大部分 ApplicationBlocks 所包含的功能。整体思路还是采用拿来主义，从开源软件提取精华，组织装配出成熟好用的框架。但是数据访问无疑是最基础、最关键的问题，涉及到性能、稳定性、易用性、开发效率等诸多问题。在这方面，开源软件有一些不足。因为用户面广，必须设计得大而全，这样在性能上、易用性上就会打一些折扣。

我对 IBatis 作了深入研究后，发现它是有很多硬伤的，例如：

第一，采用反射的方式实现ORMap，虽然对反射信息作了缓存，其性能还是比不用反射降低30％以上，尤其是在对象粒度大和数量多的时候更为明显。而这些反射其实是不必要的，完全可以通过代码生成工具生成代码，静态编译到系统中。

第二，大量的ORMap配置文件，导致项目启动缓慢，这是因为它要作根据配置文件生成大量类型反射信息缓存，要作大量装配，在调试启动项目时非常耗时，难以忍受。同上，我认为配置文件也是不必要的，这些完全可以用代码生成器生成代码静态编译到系统中。

 第三，iBatis调试太复杂，用过的都知道。因为动态生成的数据访问层没有源代码，而配置文件也容易出错，却不容易查错和诊断，明文的配置文件也会暴露一些不必要暴露的信息。

第四，iBatis的ORMap方式过于简单，直接把数据库字段值映射到对象属性是不合适的，例如数据库Number和Date类型的字段值为NULL时，在C#对象上就没法严谨地表示。这在iBatis这种类型的ORMap工具中是个不容易解决的问题。

我也研究过微软的 Enterprise Library 里的数据库访问Block，它不是 ORMap 的思路，所以就没有考虑去拿什么。不过我发现它处理存储过程的跨平台能力很强，所以从 Enterprise Library 里就拿来了这块东西。

至于NHibernate，我对它的性能没有信心，所以不考虑了。

这就是AppFramework.DBAccess组件的存在价值。

二、姗姗来迟

因为平时工作比较忙，再加上我总是比较严谨，很多细节的地方都要精益求精。最初我只实现了跨数据库的设计，能够支持连接到 SQLServer2000、Oracle和Access。后来SQL2005出来后，我利用了它支持与Oracle类似的内翻页特性，实现了内翻页功能，这样针对Oracle和SQL作大表查询时就不会有翻页性能问题了。

而后通过对ORMap的研究，我提出代码生成器，并以插件的方式植入到VS2005IDE中。

经过反复测试，已经把性能调整到接近最优了。

目前还遗留一些问题，例如对象列表的查询（类似LINQ）尚未有最佳实现，目前打算研究如何利用LINQ这一新特性来解决。

 技术总是不断推出，我不能总这么等下去，所以着手开始写产品文档了。写文档的同时，又反过来审视产品、改进产品。总之又花去不少时间，到现在文档还差2、3个章节未写完，但已能基本上把主要的功能使用叙述清楚了。

三、将来

AppFramework.DBAccess 组件已基本定型，将终身免费提供给行业各界使用，希望对大家有用，在使用中有什么问题，也可以反馈给我，我会尽力即时改进。

后续我的研究重点工作是用 Ajax / Share Point 等技术和平台构建企业各级门户，利用 WWF 等.Net新特性打造企业业务流程引擎，另外一个是研究分布式企业应用的架构。

期待与大家共同进步。