技术架构的选择-基础框架

技术架构的选择-基础框架

      入职后不久，我们研发部展开了一次又一次的头脑风暴。

      会上各抒己见，气氛良好，并且在主持人的引导下，逐一敲定，并落实到人头上。不过在基础框架 这一块显得相当棘手，也是争论最多的一块，由于这部分是技术体系的基础，因此针对基础框架的选择，决定在让同志们利用2个月的时间再次好好调研后再次碰头。这一天终于来了。

      2011年9月。是SSH、SSI、还是SSHI？实际上就是在选择是用HB还是iBatis。

 

觉得要采用iBatis的论点如下：

我仍然还是觉得用HB不如用iBatis，CSDN主持人也曾经表示，如果你们公司没有HB大牛那就不要用HB。这个东西太难上手了，光看指南就得很长时间。iBatis就不同，直观大方，易上手，而且还安全。

 

对对，我也建议废掉HB，iBatis易于上手，拿来指南不到一个礼拜就可以掌握了。而且，iBatis在sql文优化方面也很直接，易触摸掌握。

 

说到sql，一般情况下iBatis的效率要比HB高。HB用得不好的话经常出现内存溢出的问题，iBatis基本不会出现该问题。

 

我选择用iBatis，主要是写的SQL语句，基本可以直接拿到数据库上去执行测试。

 

我选择用iBatis，虽然Hibernate所谓的OO，但是有多少系统是真正使用的OO方式来设计和实现的呢。

 

 

觉得要采用HB的论点如下：

Hibernate 对于熟悉它的人，是一样非常好的工具，Hibernate 的作者也说过，只要是 Hibernate Team 的人，做出来的系统肯定性能不会差～ 但是不熟悉的人就很难说了～ 我建议使用它的人还是读读它的代码，别盲目使用。很难相象一个程序员，对它的工具做了什么都不知道，还能用好它。

我觉得，只是我们以前没有用好，造成了系统性能有问题，刚才说的内存溢出什么的。因此这不是HB本身的问题，是我们使用者的问题！如果说HB难所以我们使用的时候出现了问题，那么你怎么能够保证iBatis使用的时候不会出现问题呢

 

不管是ibatis还是hibernate归根结底还是对数据库访问。用得好的话，就算不考虑cache hibernate是不会比ibatis慢的。

 

hibernate查询方面提供了多种查询方式，如criteria,hql,native sql，只要灵活应用，基本上能涵括数据库查询的需求了

 

用iBatis能做的东西hibernate都能做，可是iBatis却不是面向对象的。

 

使用OO，在维护时才会发现好处；使用框架，也是在维护时才会发现好处。越是大项目越是如此，面向过程使得过程间难于解耦，系统扩展起来比较痛苦，咱们上一个项目就是面向过程的，现在改为面向对象了。

 

觉得两者都行的论点如下：

我hibernate用了2年，使用过程中也碰到过很多乱七八糟的问题，或者解决或者绕过了。ibatis看了一个晚上，大致了解。如果让我在ibatis和hibernate都不熟的基础上对项目的orm框架做选择，我应该会选择ibatis而不是hibernate。不过在对hibernate比较熟悉的情况下确实是选择hibernate开发效率会高。

 

待续。。。