开篇
上篇我们写了关于《关于ORM中只有XML没有映射实体的思考？期待大家的建议》这篇文章中描述了几个可能的实现思路，但是总体来说，经过大家的建议和提醒，免备案空间，我发现了一些比较好的思
路，。当然我这里结合这些思路进行整理，至
于上篇已经讲述的内容，我本文就不阐述了，下面给出其他的几个可行的思路的分析。
由于目前项目中的一些特定的需求决定，还是接着上篇给出的需求，进行了部分的修改。整理如下
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没有实体