关于ORM中只有XML没有映射实体的分析

开篇

          上篇咱们写了关于《关于ORM中只有XML没有映射实体的思考？期待你们的建议》这篇文章中描述了几个可能的实现思路，可是整体来讲，通过你们的建议和提醒，我发现了一些比较好的思

路，在这里特别感谢illumination 、金色海洋（jyk） 、贺臣 、Kevin Zou 等朋友们的支持和建议，我整理了下思路，而且通过金哥的指点得出一些新的思路。固然我这里结合这些思路进行整理，至

于上篇已经讲述的内容，我本文就不阐述了，下面给出其余的几个可行的思路的分析。

           因为目前项目中的一些特定的需求决定，仍是接着上篇给出的需求，进行了部分的修改。整理以下

           一、修改了数据库表，咱们能够不修改界面调用的应用程序代码。(因此咱们这里以前的一个思路是使用XML而不是使用实体类）。

           二、修改了模型以后。能动态的反映到数据库中(这个倒不是特别难实现的部分,并且目前已有不少成功的案例)。

           三、但愿开发人员在使用这个动态映射的平台时，可以很方便的使用(使用习惯和开发模式上，易用性等方面)。

                     四、维护性及可配置性方面的要求，而且可以很方便的进行数据库迁移(多数据的差别性的屏蔽,部署的环境差别性等)。

摘要

        在前面几位朋友的帮助下咱们能够获得如下的几类结论，下面咱们来给出以前给出的3类解决方案之间的差别性和共性，而且针对目前的根据XML来完成映射时优缺点的对比，而且来分析，看看

有没有其余的更好的途径来完成这样的映射呢？

        本文将从如下的角度来分析，分析对于上面的几个要求，来对比上篇给出的方案，而且展开来分析其余的可能的方案之间的差别性和共性，而且分析这些方案之间的优缺点。

        一、基于XML和实体形式的ORM。

        二、基于XML形式，没有实体来完成映射的ORM。

        三、基于XML而且结合字典或者咱们本身包装的单个实体类的形式。

        四、没有XML只有实体的形式，全部的映射都是经过实体来完成(经过特性或者是经过元数据)。

        五、没有XML也没有实体，而是经过字典来完成全部的映射(数据库中保存映射关系)。

        六、EntityFramework + POCO Template的方案(illumination提出的解决方案)。

        七、更多(请你们多多指点)

        下面咱们来逐个分析下吧。而且分析他们之间的差别性和优缺点。

本文大纲

         一、开篇

         二、摘要

         三、本文大纲

         四、ORM中的映射方案

         五、本文总结

         六、结论

ORM中的映射方案分析

           1、基于XML与实体

             

             目前有不少的解决方案，都是这么来作的，好比Nhibernate中的配置，咱们目前的项目中也是这样的思路，不过这样的思路，在项目的使用中有以下好处：

             一、很方便开发人员使用，开发人员不用本身维护XML，只须要维护Entity便可，咱们能够根据实体来生成XML，或者根据XML来生成实体。

             二、使用XML能够很方便的屏蔽数据库的差别性，由于通常状况下来讲数据库的差别对XML映射文件的影响不大。

             三、使用实体类的形式，能够为开发人员能够很方便的使用，避免了一些在实体使用时的拼写的错误，而且很方便调试时的跟踪。

             四、在生成SQL语句的时候，不要每次都反射实体类，只须要从XML读取便可，提升效率。

             可是也带来了如下的问题。

              一、如何将XML和实体类保持一致，一旦XML发生变动，或者目前咱们遇到的最多的问题，就是表结构发生变化，那么就须要修改实体和XML，固然也能够提供代码生成器，来反向根据

              数据库表来生成映射的实体和XML。(必须所有从新生成，编译，有些状况下咱们不但愿这样)

              二、还有就是XML太多，维护起来是个麻烦。

   2、基于XML没有实体

                       

          基于XML可是没有实体的状况下，咱们直接操做返回的datatable或者dataRow来完成对数据的访问，这样虽然能够减小实体的维护，也能处理数据库表发生变化时，只要修改下XML文件即

可，而且不须要从新修改程序也不须要编译，可是也有必定的问题，咱们下面来对比下优缺点：

          优势

          一、  不要书写实体类。

          二、  不用维护XML与实体的差别性。

          三、  不用处理一些数据转换的操做。数据映射器等。

          缺点

          一、使用不方便，例如若是使用DataRow的使用，因为是弱类型，咱们没法方便的使用。

          二、不易于调试及验证等。

          三、 难以优化性能。        

           3、基于XML与字典或自定义通用操做类

                    

           上面给出可能的映射形式，固然还有其余的变种，前面给出的形式都是咱们在上篇中给出的大体思路，本文不给出实现，只是给个思路，而且分析总结

            咱们来看看这种形式的优缺点：

            优势：

            一、实现了自定义通用实体来完成与全部XML进行映射的一种形式，这样能够方便的即便数据库表结构发生变化，或者模型发生变化时，咱们都不须要改变咱们的具体代码。

            二、由于咱们这里的通用实体负责全部实体的数据的承载。因此咱们对该通用对象进行开发便可，能够方便用户使用。

            缺点：

            一、须要实现大量的底层通用对象功能。

            二、开发人员使用的过程当中，仍然没法像强类型对象同样，能够经过属性来访问实体的数据信息，咱们仍是职能经过字典中的键值对的形式来访问，无疑会带来必定的难用性。

            三、若是底层提供的功能不足或者对易用性方面的提供不足，会下降开发效率。

            四、调试及跟踪方面仍是不太方便。

           4、基于实体映射

                      

            若是咱们不使用XML，而是之间采用实体映射的形式来完成ORM，那么无疑是最方便，也是效率最高的形式，由于不须要考虑一些转换过程当中出现的一些性能的损失等方便，至少能够说，这

样的形式，是性能损失相对来讲很小的形式。前面的ORM系列中，我已经给出了部分实现，采用的是特性+反射的形式，来完成ORM，采用特性+反射的形式，可能性能上会有损失，可是若是采用的

缓存得当，那么效率上不会差太多的。

            那么咱们来分析下，采用这样的形式的优缺点吧

            优势

            一、一个实体类，对应数据库中的一张表，那么有了实体类，使用起来很方便。

            二、调试及跟踪时，能够及时查看信息，很方便。

            三、在调优及其余等方面能够很方便的进行操做。

            四、避免了一些验证方面的错误。

            缺点

            一、若是数据库表结构或者实体发生变化都须要同步修改，不然会出现不可预料的错误。

            二、若是修改了数据库表，那么实体必须同步更新，而且还须要编译。灵活性方面较差。

            三、若是采用反射的形式，那么可能性能上是个瓶颈

           5、无(XML与实体)

                       

             经过一个通用的实体，来完成ORM映射，这时候，咱们没有为数据库表中的每一个表写一个映射实体，咱们经过在数据库一个元数据表中，记录这些与表进行映射的实体的相应信息，而后咱们

在通用实体中,去自动的填充通用实体对象，这样就获得这样的思路：

             

             经过ORM，咱们可以得出以下的优缺点的对比

             优势：

             一、既不须要维护XML，也不须要维护实体。

             二、不管是表发生变化，仍是实体模型发生变化，咱们都可以作到数据库的自动同步。好比经过触发器来完成或者是存储过程。

             三、数据的一致性和性能相对来讲比较高。

             四、可维护较高。

             缺点：

             一、都放在数据库中，使用的时候，仍是要经过键值对的形式来读取或者设置属性。

             二、对于关联关系的对象，处理起来不是很方便。

             三、缓存的策略很难制定。

             四、数据库差别性的移植等。

           6、EntityFramework + POCO Template的方案

                       通过illumination的介绍，我也看了一下EntityFramework 的相关教程，具体的实现思路，我就不班门弄斧了，等具体研究完毕后，我会放出demo出来。

           7、其余方案

             但愿你们能提出不一样的方案和思路，但愿你们指出批评。

总结

             本文分析了几类可能的ORM形式，固然市面上的一些集成的ORM框架，应该都是这样大部分思路上都会或多或少的采用前面给出的几类思路，固然若是您还有其余的思路，那么请你提出来

             本文也是对比分析了每种形式的从我自身理解的优缺点，可能部分总结的不到位，或者说说说的不正确等，都请您指出，谢谢！

结论

             经过上面的几个分析，若是咱们必须采用基于XML的，而且要求可以灵活的配置，那么可能仍是使用通用映射对象来作会比较好，这样不但可以达到XML的灵活配置，并且相对字典来讲，使

用起来也仍是会方便一些。而且经过自定义对象提供一些基础的验证等其余功能的集成等，都可以丰富咱们的操做，因此可能最理想的方案是这样的，基于目前的项目状况所决定！