【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 
开篇
上篇我们写了关于《关于ORM中只有XML没有映射实体的思考？期待大家的建议》这篇文章中描述了几个可能的实现思路，但是总体来说，经过大家的建议和提醒，我发现了一些比较好的思
路，在这里特别感谢illumination 、金色海洋（jyk） 、贺臣 、Kevin Zou 等朋友们的支持和建议，我整理了下思路，并且经过金哥的指点得出一些新的思路。当然我这里结合这些思路进行整理，至
于上篇已经讲述的内容，我本文就不阐述了，下面给出其他的几个可行的思路的分析。
由于目前项目中的一些特定的需求决定，还是接着上篇给出的需求，进行了部分的修改。整理如下
1、修改了数据库表，我们可以不修改界面调用的应用程序代码。(所以我们这里之前的一个思路是使用XML而不是使用实体类）。
2、修改了模型之后。能动态的反映到数据库中(这个倒不是特别难实现的部分,而且目前已有很多成功的案例)。
3、希望开发人员在使用这个动态映射的平台时，能够很方便的使用(使用习惯和开发模式上，易用性等方面)。
4、维护性及可配置性方面的要求，并且能够很方便的进行数据库迁移(多数据的差异性的屏蔽,部署的环境差异性等)。
摘要
在前面几位朋友的帮助下我们可以得到以下的几类结论，下面我们来给出之前给出的3类解决方案之间的差异性和共性，并且针对目前的根据XML来完成映射时优缺点的对比，并且来分析，看看
有没有其他的更好的途径来完成这样的映射呢？
本文将从以下的角度来分析，分析对于上面的几个要求，来对比上篇给出的方案，并且展开来分析其他的可能的方案之间的差异性和共性，并且分析这些方案之间的优缺点。
1、基于XML和实体形式的ORM。
2、基于XML形式，没有实体来完成映射的ORM。
3、基于XML并且结合字典或者我们自己包装的单个实体类的形式。
4、没有XML只有实体的形式，所有的映射都是通过实体来完成(通过特性或者是通过元数据)。
5、没有XML也没有实体，而是通过字典来完成所有的映射(数据库中保存映射关系)。
6、EntityFramework + POCO Template的方案(illumination提出的解决方案)。
7、更多(请大家多多指点)
下面我们来逐个分析下吧。并且分析他们之间的差异性和优缺点。
本文大纲
1、开篇
2、摘要
3、本文大纲
4、ORM中的映射方案
5、本文总结
6、结论
ORM中的映射方案分析
一、基于XML与实体
目前有很多的解决方案，都是这么来做的，比如Nhibernate中的配置，我们目前的项目中也是这样的思路，不过这样的思路，在项目的使用中有如下好处：
1、很方便开发人员使用，开发人员不用自己维护XML，只需要维护Entity即可，我们可以根据实体来生成XML，或者根据XML来生成实体。
2、使用XML可以很方便的屏蔽数据库的差异性，因为一般情况下来说数据库的差异对XML映射文件的影响不大。
3、使用实体类的形式，可以为开发人员可以很方便的使用，避免了一些在实体使用时的拼写的错误，并且很方便调试时的跟踪。
4、在生成SQL语句的时候，不要每次都反射实体类，只需要从XML读取即可，提高效率。
但是也带来了以下的问题。
1、如何将XML和实体类保持一致，一旦XML发生变更，或者目前我们遇到的最多的问题，就是表结构发生变化，那么就需要修改实体和XML，当然也可以提供代码生成器，来反向根据
数据库表来生成映射的实体和XML。(必须全部重新生成，编译，有些情况下我们不希望这样)
2、还有就是XML太多，维护起来是个麻烦。
二、基于XML没有实体
基于XML但是没有实体的情况下，我们直接操作返回的datatable或者dataRow来完成对数据的访问，这样虽然可以减少实体的维护，也能处理数据库表发生变化时，只要修改下XML文件即
可，并且不需要重新修改程序也不需要编译，但是也有一定的问题，我们下面来对比下优缺点：
优点
1、 不要书写实体类。
2、 不用维护XML与实体的差异性。
3、 不用处理一些数据转换的操作。数据映射器等。
缺点
1、使用不方便，例如如果使用DataRow的使用，由于是弱类型，我们无法方便的使用。
2、不易于调试及验证等。
3、 难以优化性能。
三、基于XML与字典或自定义通用操作类
上面给出可能的映射形式，当然还有其他的变种，前面给出的形式都是我们在上篇中给出的大致思路，本文不给出实现，只是给个思路，并且分析总结
我们来看看这种形式的优缺点：
优点：
1、实现了自定义通用实体来完成与所有XML进行映射的一种形式，这样可以方便的即使数据库表结构发生变化，或者模型发生变化时，我们都不需要改变我们的具体代码。
2、因为我们这里的通用实体负责所有实体的数据的承载。所以我们对该通用对象进行开发即可，可以方便用户使用。
缺点：
1、需要实现大量的底层通用对象功能。
2、开发人员使用的过程中，仍然无法像强类型对象一样，可以通过属性来访问实体的数据信息，我们还是职能通过字典中的键值对的形式来访问，无疑会带来一定的难用性。
3、如果底层提供的功能不足或者对易用性方面的提供不足，会降低开发效率。
4、调试及跟踪方面还是不太方便。
四、基于实体映射
如果我们不使用XML，而是之间采用实体映射的形式来完成ORM，那么无疑是最方便，也是效率最高的形式，因为不需要考虑一些转换过程中出现的一些性能的损失等方便，至少可以说，这
样的形式，是性能损失相对来说很小的形式。前面的ORM系列中，我已经给出了部分实现，采用的是特性+反射的形式，来完成ORM，采用特性+反射的形式，可能性能上会有损失，但是如果采用的
缓存得当，那么效率上不会差太多的。
那么我们来分析下，采用这样的形式的优缺点吧
优点
1、一个实体类，对应数据库中的一张表，那么有了实体类，使用起来很方便。
2、调试及跟踪时，可以及时查看信息，很方便。
3、在调优及其他等方面可以很方便的进行操作。
4、避免了一些验证方面的错误。
缺点
1、如果数据库表结构或者实体发生变化都需要同步修改，否则会出现不可预料的错误。
2、如果修改了数据库表，那么实体必须同步更新，并且还需要编译。灵活性方面较差。
3、如果采用反射的形式，那么可能性能上是个瓶颈
五、无(XML与实体)
通过一个通用的实体，来完成ORM映射，这时候，我们没有为数据库表中的每个表写一个映射实体，我们通过在数据库一个元数据表中，记录这些与表进行映射的实体的相应信息，然后我们
在通用实体中,去自动的填充通用实体对象，这样就得到这样的思路：
通过ORM，我们能够得出如下的优缺点的对比
优点：
1、既不需要维护XML，也不需要维护实体。
2、无论是表发生变化，还是实体模型发生变化，我们都能够做到数据库的自动同步。比如通过触发器来完成或者是存储过程。
3、数据的一致性和性能相对来说比较高。
4、可维护较高。
缺点：
1、都放在数据库中，使用的时候，还是要通过键值对的形式来读取或者设置属性。
2、对于关联关系的对象，处理起来不是很方便。
3、缓存的策略很难制定。
4、数据库差异性的移植等。
六、EntityFramework + POCO Template的方案
经过illumination的介绍，我也看了一下EntityFramework 的相关教程，具体的实现思路，我就不班门弄斧了，等具体研究完毕后，我会放出demo出来。
七、其他方案
希望大家能提出不同的方案和思路，希望大家指出批评。
总结
本文分析了几类可能的ORM形式，当然市面上的一些集成的ORM框架，应该都是这样大部分思路上都会或多或少的采用前面给出的几类思路，当然如果您还有其他的思路，那么请你提出来
本文也是对比分析了每种形式的从我自身理解的优缺点，可能部分总结的不到位，或者说说说的不正确等，都请您指出，谢谢！
结论
通过上面的几个分析，如果我们必须采用基于XML的，并且要求能够灵活的配置，那么可能还是使用通用映射对象来做会比较好，这样不但能够达到XML的灵活配置，而且相对字典来说，使
用起来也还是会方便一些。并且通过自定义对象提供一些基础的验证等其他功能的集成等，都能够丰富我们的操作，所以可能最理想的方案是这样的，基于目前的项目情况所决定！
来源：oschina
链接：https://my.oschina.net/u/125879/blog/14222