轻量级持久层的讨论
代码与模板已经发布，下载请到《轻量级持久层的讨论(代码与模板_V2)》
最近忙里偷闲做了一个级持久层，基础代码都已经完成，CodeSmith使用的模板也已完成，但是还没有充分测试所以先不发布，写这篇文章的主要目的是征集下博客园的各位大哥对这个级持久层的意见。
这个框架为了提高效率所以没有采用反射机制，而是使用一个表对应一个实体类和实体对象数据操作类的形式。换句话说就是每一个表都有一个实体类（Entity）和实体对象数据操作类（DataProvider）与只对应。DataProvider提供对一张表的增，删，改，查的功能，并以实体类对象的形式传递数据和返回结果。
而目前比较完善的框架采用更多的是以一个或者一组协同工作的通用数据操作类来组成一个持久层框架，可以对任何实体类进行各种操作。我一直觉得这种封装会更加“漂亮”。
但是一个数据操作类对应所有实体类就不可避免的需要用到反射来动态创建Sql语句与实体对象，从而影响系统性能，并且从实用性考虑，更简洁更优美的封装性并不只是为了好看，而是为了提高代码重用率并提高开发和维护的效率。
既然现在可以使用CodeSmith这样的代码生成工具来生成实体类与数据操作类的代码，那么适当降低封装性以提高系统执行效率我觉得还是可取的。
现在要考虑的就是怎样让数据操作类（DataProvider）可以与数据库类型无关，以做到不用修改代码的迁移数据库。
我用的方法也是大家很普遍采用的方法，就是做一个DataAccess类提供各种数据库操作接口，与数据库操作对象实例化接口，DataAccess的各各对应与不同数据库类型的子类来完成创建数据库操作对象实例的任务。DataAccess再提供一个静态接口，根据配置文件中的配置来决定实例化时采用哪个子类型。
我对这个级持久层的定位是轻量级，它的数据层用的是完全自己DIY的数据层而不是微软企业类库提供的有各种复杂接口的DataAccess，并且为这个框架配上：实体类模板，数据操作类模板，数据操作测试类模板，后台管理页面模板。让使用的人可以全身心的投入到对系统业务操作与需求的考虑中。
框架的类图如下(点击看大图)：
DataAccess和它的那些子类就不用介绍了，大家肯定是看得不爱看了，这个DataAccess与众不同的地方稍微介绍下。
我做的这个DataAccess的不同之处就是有一个ExecuteBatch方法用于执行批处理，这个方法执行一组ExecuteBatchItem类型列表包含的批处理操作，这组批处理操作可以被包含在同一个事务处理当中，并且每个批处理项都可以设置两个事件，一个是塔被执行前触发的事件，一个是它被执行过后触发的事情，通过这两个事件我们可以获取批操作被执行的情状。对于这个方法我觉得还是满有用的，不知道博客园的各位大侠如何看待。
DataProvider就是所有DataProvider的父类，它定义了对被映射表进行增，删，改，查的接口。
DataProvider对表的操作可以细化到只对某个列进行插入和修改与及获取，这是很多持久层框架做不到的。但是目前还没办法做到级连的删除和修改，只能在生成完代码后自己再根据需要对具体表的DataProvider进行修改。
我很希望能有更多的朋友可以提出对这个框架的看法，不管是觉得好还是觉得不好。一方面可以让我知道我的工作还是有人感兴趣或者用得着，另外一方面也可以让我不断完善这个框架。
框架的代码和模板预定与下星期一发布，多做些测试以防万一。
（PS：这个思路不是我一人的成果，因为我是特别喜欢代码通用，也就是可以约抽象出通用代码我越高兴，后来听项目经理老蔡一说又觉得的确反射和过度复杂的封装不太适合用于B/S架构开发，并且现在CodeSmith可以生成大部分代码了，降低代码重用率也是无妨）
2006-04-20 09:45 补充：
现在有一个改进封装性的想法，就是把更具实体对象类型创建Sql语句与Sql参数所需要的信息保存在另外一个与实体类对应的类里，这个类同样可以根据表结构通过CodeSmith生成代码，这样获取就可以花比较的小性能代价来做到统一用一个DataProvider对所有Entity类型对象进行操作。但是只是想法，需要实践来验证可行性.......
2006-04-20 09:48 补充：
网友henry提示可以使用Emit和CodeDom来提高反射性能，我看了他的文章中的评测，的确效率比光用反色高很多，看了可以考虑使用反射做一个通用的DataProvider了，不过我还是决定先留着目前的DataProvider因为目前模板已经做了。等有空做个反射版的就添加到另外一个命名空间里，做为级持久层可选的功能，让使用者决定自己的系统具体要用什么样的级持久层。再次感谢henry。
2006-04-20 20:19 加班很累补充：
呵呵，偶只是个即将毕业的专科生，水平有限让大家见笑了。我知道我还有很多东西需要努力学习的。谢谢大家积极的参与级持久层的讨论。
2006-04-21 08:59 上班偷闲补充：
嘿嘿，我觉得我这个级持久层并不属于ORM框架，起码不完全属于。在我理解的ORM是要能把对象关系映射出来，而我这个级持久层只能映射表结构，不能映射表关系，我会努力做到映射表关系的：)
最近忙里偷闲做了一个级持久层，基础代码都已经完成，CodeSmith使用的模板也已完成，但是还没有充分测试所以先不发布，写这篇文章的主要目的是征集下博客园的各位大哥对这个级持久层的意见。
这个框架为了提高效率所以没有采用反射机制，而是使用一个表对应一个实体类和实体对象数据操作类的形式。换句话说就是每一个表都有一个实体类（Entity）和实体对象数据操作类（DataProvider）与只对应。DataProvider提供对一张表的增，删，改，查的功能，并以实体类对象的形式传递数据和返回结果。
而目前比较完善的框架采用更多的是以一个或者一组协同工作的通用数据操作类来组成一个持久层框架，可以对任何实体类进行各种操作。我一直觉得这种封装会更加“漂亮”。
但是一个数据操作类对应所有实体类就不可避免的需要用到反射来动态创建Sql语句与实体对象，从而影响系统性能，并且从实用性考虑，更简洁更优美的封装性并不只是为了好看，而是为了提高代码重用率并提高开发和维护的效率。
既然现在可以使用CodeSmith这样的代码生成工具来生成实体类与数据操作类的代码，那么适当降低封装性以提高系统执行效率我觉得还是可取的。
现在要考虑的就是怎样让数据操作类（DataProvider）可以与数据库类型无关，以做到不用修改代码的迁移数据库。
我用的方法也是大家很普遍采用的方法，就是做一个DataAccess类提供各种数据库操作接口，与数据库操作对象实例化接口，DataAccess的各各对应与不同数据库类型的子类来完成创建数据库操作对象实例的任务。DataAccess再提供一个静态接口，根据配置文件中的配置来决定实例化时采用哪个子类型。
我对这个级持久层的定位是轻量级，它的数据层用的是完全自己DIY的数据层而不是微软企业类库提供的有各种复杂接口的DataAccess，并且为这个框架配上：实体类模板，数据操作类模板，数据操作测试类模板，后台管理页面模板。让使用的人可以全身心的投入到对系统业务操作与需求的考虑中。
框架的类图如下(点击看大图)：
DataAccess和它的那些子类就不用介绍了，大家肯定是看得不爱看了，这个DataAccess与众不同的地方稍微介绍下。
我做的这个DataAccess的不同之处就是有一个ExecuteBatch方法用于执行批处理，这个方法执行一组ExecuteBatchItem类型列表包含的批处理操作，这组批处理操作可以被包含在同一个事务处理当中，并且每个批处理项都可以设置两个事件，一个是塔被执行前触发的事件，一个是它被执行过后触发的事情，通过这两个事件我们可以获取批操作被执行的情状。对于这个方法我觉得还是满有用的，不知道博客园的各位大侠如何看待。
DataProvider就是所有DataProvider的父类，它定义了对被映射表进行增，删，改，查的接口。
DataProvider对表的操作可以细化到只对某个列进行插入和修改与及获取，这是很多持久层框架做不到的。但是目前还没办法做到级连的删除和修改，只能在生成完代码后自己再根据需要对具体表的DataProvider进行修改。
我很希望能有更多的朋友可以提出对这个框架的看法，不管是觉得好还是觉得不好。一方面可以让我知道我的工作还是有人感兴趣或者用得着，另外一方面也可以让我不断完善这个框架。
框架的代码和模板预定与下星期一发布，多做些测试以防万一。
（PS：这个思路不是我一人的成果，因为我是特别喜欢代码通用，也就是可以约抽象出通用代码我越高兴，后来听项目经理老蔡一说又觉得的确反射和过度复杂的封装不太适合用于B/S架构开发，并且现在CodeSmith可以生成大部分代码了，降低代码重用率也是无妨）
2006-04-20 09:45 补充：
现在有一个改进封装性的想法，就是把更具实体对象类型创建Sql语句与Sql参数所需要的信息保存在另外一个与实体类对应的类里，这个类同样可以根据表结构通过CodeSmith生成代码，这样获取就可以花比较的小性能代价来做到统一用一个DataProvider对所有Entity类型对象进行操作。但是只是想法，需要实践来验证可行性.......
2006-04-20 09:48 补充：
网友henry提示可以使用Emit和CodeDom来提高反射性能，我看了他的文章中的评测，的确效率比光用反色高很多，看了可以考虑使用反射做一个通用的DataProvider了，不过我还是决定先留着目前的DataProvider因为目前模板已经做了。等有空做个反射版的就添加到另外一个命名空间里，做为级持久层可选的功能，让使用者决定自己的系统具体要用什么样的级持久层。再次感谢henry。
2006-04-20 20:19 加班很累补充：
呵呵，偶只是个即将毕业的专科生，水平有限让大家见笑了。我知道我还有很多东西需要努力学习的。谢谢大家积极的参与级持久层的讨论。
2006-04-21 08:59 上班偷闲补充：
嘿嘿，我觉得我这个级持久层并不属于ORM框架，起码不完全属于。在我理解的ORM是要能把对象关系映射出来，而我这个级持久层只能映射表结构，不能映射表关系，我会努力做到映射表关系的：)
