论数据库访问组件的选择--火地晋大作读后感-阿里云开发者社区

开发者社区> 数据库> 正文

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

简介: 前言 火地晋做了一件有意义的事情。把这些ORM对比了一下(http://www.cnblogs.com/yelaiju/p/3209506.html)。 这里要讨论一下我们用一个什么样的策略来选择数据库访问组件。

前言

火地晋做了一件有意义的事情。把这些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。

 

 

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章