物业

struts、spring、hibernate/ibatis你会删除那个？为什么？

struts、spring、hibernate/ibatis你会删除那个？为什么？

这是一道面试题，我当时犹豫了一下，说会删除struts。

面试官问为什么，我说去掉struts，可以用servlet来替你它，毕竟action层的作用使用servlet完全可以替代。

作用：接受客户端的请求，负责分发至相应的action，通过actionForm拿到相应数据，调用相应的service层，负责转向相应的页面。

回答完之后，又想到了，ibatis或者hibernate的作用使用jdbc不是也能替代吗？

作用：完成一个对象与数据库打交道的过程。也使得开发更具对象化，在某种情况下也提高了生产力，移值性会非常容易，sql语句和代码的分离，使得维护更加容易。

而spring随然说现在还没有一个可行的方案来替代他，但是如果完全不使用它，也不是没有可能。

作用：声明事务，依赖注入，解耦合，配置客户端访问应用程序的方式是单实例还是多实例。

这个应该是在hibernate ibatis里面来选，，因为这两个都是orm框架。其作用也差不多。

知道这个之后就简单了。。

其实面试官真正想问你的是，hibernate和ibatis的优缺点。。

你了解他们的优缺点之后，那么就好回答了。。

在什么情况下删除哪个，什么情况下删除另外个。也就是在什么情况下用hibernate,什么情况下用ibatis。

上很多他们的区别。说得也还可以。。

其实真正的用什么框架是要针对项目而言，所以面试官的意思不是真的要你给他一个准确答案。。但是要说得合情合理。

我选ibatis，虽然ibatis上手容易，可以编写更加灵活的SQL语句。

但是，感觉这样会使得开发的工作量非常大。

我们公司从来都是一个人搞定一个项目，

这样的情况下，使用Hibernate3在不使用配置文件（使用Annotation）的情况下，很快就能完成持久层的开发。

而使用ibatis呢？没一个交互过程都要写一个SQL语句，配置文件还有处理映射关系。

最起码，代码量是上去了。

干得多了，就会感觉特别麻烦，有时候总在想，还不如直接JDBC来得快些。

我会选择struts。

对于MVC的完美体现 struts在新一带技术面前显的比较脆弱。它只能看做是servlet的扩展，本人认为项目中可有可无。虽然struts2加入了ajax，

我认为这是struts2的一个败笔。

spring 不用说了，一个高性能、高扩展、面向接口的思想 、多种设计模式融合在一起的优秀容器。

hibernate和ibatis 都还不错。对于dao层的设计目前经常用到。

如果删除了 struts可以用servlet来代替，也可以用springMVC来代替。我们目前的项目是springMVC+hibernate.

我肯定留下Spring

另外2个删除哪个要看具体的情况了~

比如业务逻辑超级复杂,并且要求数据访问灵活我会把ORM工具去掉直接用JDBC

如果WEB方面要求Ajax比较多,我会把Struts去掉

如果一定要权责的话，我会选择Hibernate的，同是ORM组件的iBatis比它更加轻便。

退一万步在说和数据库交互JDBC都足够用了。

而作为控制的struts和作为容器的spring应该是不可或缺的吧

个人觉得只需要SPRING，因为struts对程序而已没有多大的优化了。hibernate对SQL优化很有限制，如果是大量数据的话比如银行，移动hibernate 根本就不行，还不如直接用JDBC连接，搞个公共类，既简单也轻量。

要我回答没准是spring！也没准是hibernate/ibatis

企业程序基本类似数据中心。共享性也不高。spring强调非侵入，对象创建方式。恰恰击中spring软肋，优点到变成缺点。

spring的确规定了VIEW操作，真要是做了，美观就难做。

spring反射对象基本双倍。而且经常包冲突。稳定性也不高。前置监听，环绕监听我采用struts2.1拦截器代替。

struts2.1+ 本身就有反向映射注入功能。

最终程序定性：

struts2.1 + JDBC3.0 + EJB3.0 +一个缓存产品。

看项目的大小：

如果项目大应用的数据表多的，客户发送的请求多，我一个也不会删！

数据表多，客户发送的请求少删struts：数据表多就应该用hibernate和spring的组合

数据表少，客户发送的请求多删hibernate。

但它真的发挥作用了 项目小我会只用struts：