论数据库访问组件的选择--火地晋大作读后感

前言

火地晋做了一件有意义的事情。把这些ORM对比了一下(http://www.cnblogs.com/yelaiju/p/3209506.html)。

这里要讨论一下我们用一个什么样的策略来选择数据库访问组件。通常有如下几种情况来选择：

1. 基于过去的经验

   比如过去用过某某ORM，在将来的项目中继续用的话经验和熟练度就会比较高。这是建立在对该ORM的信任基础之上的。

2. 别人介绍或者在网上自己发现的，然后再试用也不错

  这种情况也挺普遍的。业界同事介绍某某ORM不错，或者在网络上发现一个数据库访问框架不错。再经过试用，发现还不错。就在项目中采用。

选择原则

  上述这两种情况中都有试用或者使用的经历，在试用和使用过程中我们考察什么呢， 主要是这些：

1. 便利性

  调用是否方便。是否易用。团队是否容易采用。

2. 性能

  该ORM或者数据库访问框架是否提供足够好的数据库访问性能。

3. 多线程情况下有否限制

  多线程情况是程序中一个很普遍的现象，该ORM或者框架是否在多线程情况下有限制。这是一个必须通过的考察项目，如果不能通过的话，最好不要选用该ORM或者框架。

4. 事务处理是否足够完备

  单个数据库的事务处理是否支持，分布式数据库事务是否支持。支持的数据库事务协调器是哪些。分布式数据库事务不是必须的。不需要分布式事务的情况下，某些ORM或者框架不支持分布式事务是允许的。但是单个数据库的事务处理是必须要支持的。不然该ORM或者框架是不能选择的。

5. 安全性

  对于防止SQL 注入有没有提供措施。这是必须的。

6. 可扩展性

  当ORM或者框架现有功能不足以满足项目要求，比如ORM产生的SQL不够优化，怎么办？有没有扩展的方法来解决。这个不是必须的，但是有的话更好。

7. 可维护性

 可维护性指的是该ORM或者框架有没有人持续提供升级，维护；如果一个框架用的人手少，然后维护它的人很久都不出维护版本，我们估计就很难选择这样的框架了。然后就是我们本身可否看到其源码，了解其本身是如何运作的。我们从而可以写出更配合的代码来。如果看不到源吗，这方面就会减分。

 

结论

  我们可以选择的ORM或者框架很多。每个ORM或者框架在这几个方面的得分是不一样的。我们其实没有那么多时间去使用那么多的ORM或者框架。只有从知道的几个当中选一个。在所有ORM之外，我们其实还有一个ado.net的选择， ado.net的方式，其性能可以做到最好，但是其便利性不如那些ORM，还有可维护性也不是足够好。所有这些选项都经过我们的考察，才能选中合适项目的数据库访问框架或者技术。

  这里的建议是我们还是尽量用那些使用面比较广的，开源的，经常更新的ORM或者框架。像那些不开源的，更新没保障的，品质没保障的ORM或者框架，最好还是别用。当然了，你要用的话，后果自付。只有在极端要求性能的情况下或者是当你有办法提高ado.net的便利性和可维护性的情况下，才去选择ado.net。