彩票走势图

一、基于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的灵活配置，而且相对字典来说，使

　　用起来也还是会方便一些。并且通过自定义对象提供一些基础的验证等其他功能的集成等，都能够丰富我们的操作，所以可能最理想的方案是这样的，基于目前的项目情况所决定！