诚心请教：spring到底好在哪里？使用spring的理由是什么？

http://baike.baidu.com/view/23023.htm
自己去看看

额，貌似这个我也不知道哦
我用spring就是管理ssh，实现运行时注入
用接口形式来实现功能，具体好在哪里，理由是啥
我还真不知道

我并不认为 Spring 有多好，极其繁多且扰乱思维的配置文件。另外，不管大小程序，都有事没事要你用 IoC 整个接口出来，感觉有点为了接口而接口。

至于 SSH 为啥如此火爆，我想主要的原因还在于人云亦云的结果。就目前的情况看下来，好多人认为 Java 的框架只有 SSH 了，很多人连 JDBC、Servlet、XML 都用不熟就直接去整 SSH 去了，导致的后果就是急于求成。

有了Spring就不再为数据库连接池发仇了（Spring 对本人最大的用处），还有就是解藕合（很多时候解不解都无所谓）

对于大项目来说用spring是不错的通常对于一个项目维护的开销(时间金钱人力物力等)是开发的开销的两倍 spring的好处就体现在维护上包括重用性扩展性等至于小项目还不一定用java

主要是切面和事务处理，spring 的MVC也用过，不过总感觉struts要好点。

唉，我们这些没用过ejb的后辈是没法体会的，如果你用ejb做大型企业级开发做个1，2年，然后用spring做做看，就知道了。实践才是检验真知的唯一方式。

以前一直在用SSH,最近在尝试不用SSH布署个项目看看
于是自己写hibernate的ORM,自己写spring的IOC/DI,自己写struts的转发控制,spring的AOP还没弄明白所以就暂时没用上,其实弄来弄去也就是MAP和反射.
个人觉得有现成的成熟的框架能用为什么不用?又方便,又能起到一定的规范作用(指MVC、IOC、OO、ORM规范),还能定制自己要的功能!
当然如果你喜欢,你依然可以为每个查询操作写SQL语句,依然可以把存储的东西看成是关系,而不是对象.
也许你更喜欢将程序依赖于具体的东西而不是抽象的类或方法.或者你觉得在web.xml中写上一大堆Servlet看起来更顺眼,更容易维护,你能更好地对各个Servlet进行分组,能更好地用拦截器、过滤器对它们进行插拔式地管理,那么请继续,Patrick Lightbody、Craig McClanahan、Rod Johoson、Gavin King都会理解你的！
并不是说只能用SSH，SSH只是一个代表，框架有很多，选择用或不用、用哪些都是个人依实际情况选择的！

如果你不用EJB做开发，建议首选Spring框架来做J2EE项目，这是目前工业级J2EE软件为数不多的解决方案中最出色的。它至少有如下优点：
1、分层解藕特性：不会让程序陷入软件泥潭
2、切面编程特性：最成功的应用是在控制数据库事务，程序不必关心是ORM或者你的连接是如何打开和关闭数据库连接的。你可以利用这种技术在庞大的项目中横着切一刀插入自己特色的技术需求，例如权限检查，敏感词、漏洞注入、挂马类威胁元素检查等等
3、封装了大部分J2EE应用：例如JavaMail，JMS，WebService、线程池、任务调度等等，这些注入后拿来就用，能节省60%以上代码量。
4、一个出色的子集——Spring MVC，它在早期版本中就支持Html上的form表单与后台Pojo绑定，即使复杂的数据类型(例如一个表单控件对应自己编写的一个类)，一个属性编辑器就可以搞定。2.5版本以后全面支持注解，也称@MVC，只要把基础的配置在xml文件里写好，以后几乎不用和xml文件打交道，它灵活得让人难以想像。后台多对一、一对多或多对多保存甚至修改，前台只需要一个form表单来接收数据就够了。在Java社区里，Apache是比SpringSource知名度大，这也是程序员，尤其是中国的程序员没用Spring MVC的最大原因。但在Spring集成开发中，有这么一个强大的web层框架，何必还集成一套Struts？我认为SJ(Spring+JPA，可用Hibernate实现)要比SSH架构方式优雅得多，SJ架构足以解决庞大的J2EE应用。
5、还有安全框架、动态语言一大把的应用
......尤其是刚在J2EE里编程的程序员，建议看重Spring框架，也许是其作者除了是计算机专业外，还是一位优秀的音乐博士，这种天份铸就了优雅程序的基础，写出来的代码就是不一样。

事务,安全,日志
ioc/aop你试一下不用spring做一下事务,再用spring做一下就感觉到了.其他也一样.

  好处的话，DI你可以不用自己创建对象啊，可以注入进来啊。
  AOP 可以在你代码中横插一段代码啊，就像 Struts2的拦截器啊
  好处是蛮多的，就是配置文件多了点。

to sunjinyujeep: 谢谢你提供的链接。讲的很全面，但是内容有些笼统，还需要消化，呵呵。
to liguominz：肺腑之言，不用多说，诚实。
to 火龙果@菜菜宝宝:对spring不同的声音，其实我似乎也是一个spring的反对者。总感觉它的东西有点唬人。

不知道是不是通过spring与hibernate 整合的方式处理你的持久层。
如果只是为了数据库的连接池问题，用spring似乎多余了哦。hibernate本身可以配置连接池，proxool 等东西也是非常不错的。很欣赏"很多时候解不解都无所谓"这句话，解耦是那些大师们追求的东西（当然我们也要尽量注意解耦）。
但感觉通过DI的方式解耦，其实就是把我们原来的工厂搬到配置文件里面了。不知道为什么spring 会拿这个来大肆宣传。

恩。应该有这方面的好处，能控制做到面向接口编程，对维护上肯定有帮助。
但是如果在大项目运用，配置文件似乎就能把人给砸死
如果一个系统有700以上的table,hibernate的配置，spring的配置my god....

其实，不管什么东西都有他的优点和缺点，例如你要是只是做一个简单的登录要用SSH框架纯粹是浪费，那spring也不好用了，但是你要是处理的逻辑比较复杂，就用把所有的对对象交给spring来管理就会比不用简单的多了！
这是我的个人意见，仅供参考！！！

to 大王让我来巡山啊、热心的小强！、小鲁：AOP应该算是一种编程思想，用spring可以轻松做到，这应该是用spring的比较好的理由。

题外话：EJB其实没有网上说的那么恶魔，只是开始接触它时，经常被弄的比较晕，即使弄出一个可以运行的示例程序，也不知道真正的原理。
顺便做个广告：Head First EJB 绝对是一本值得看的书（看了之后，突然感悟，原来EJB就那么回事）
再推荐一本：Head First 设计模式。

spring确实可以和一些框架集成，但不用spring，并不意味着我要重新制造轮子，比如mvc,OR/MAP。
（只是说出我的想法，没有冒犯的意思，忘见谅）

用了spring只会使开发周期更长，所以要从效率来看struts+hibernate的组合是最好的！

1、AOP-面向切面编程对业务过程处理进行提现。2、有自己的框架（虽然用起来，很少）

感谢留言，写这么多，辛苦！
回复第一点：分层解耦特征，我还没搞清楚，等下查查。
      二  ：AOP，认同，spring确实可以带来这方面的好处。
      三  : 还没有对spring研究的这么深入，但是JavaMail，JMS，WebService、线程池,这些东西，应该是spring能集成进来的吧。如果不用spring，这些东西我也可以随便组合着用。？
      五  ：彻底的不了解。嘎嘎

感谢fan578和bolink5 两位美女的回复。代码界美女不多啊。

我是觉得这个框架对我的帮助不是很大，没有象之前的MVC框架让我“为之一震”的感觉。

下面这些是原来在 http://topic.csdn.net/u/20090504/17/969c7340-ebbe-4b79-b579-2d4563bb6de7.html 这个帖子中的回复，有兴趣的话可以看一下。下面是我对一些开源框架的观点：Spring
优点：IoC、AOP 容器，集大成者，集众框架，可谓包罗万象，应有尽有，学习资料丰富
缺点：极其繁杂的配置文件，原来有个 Spring 的项目，配置文件就有 8000 多行，可以把人看晕掉，极其不喜欢！大事小事都得弄个接口，感觉是为了接口而接口，估计有好多人是先写类再写接口的吧？复杂的配置文件与过度的分层直接导致的后果就是开发效率低下！Hibernate
优点：ORM 的领头羊，ORM 事实上的标准，功能完善，学习资料丰富
缺点：在效率上有些问题，加之含有许多的 hbm 配置文件强行与实体代码分隔。Struts 1.x
优点：老牌 MVC 框架，MVC 事实上的标准
缺点：说实在的我感觉除了比 Servlet 少在 web.xml 中配置一些东西、自动封装 FormBean 之外，没感觉到有什么好处，这个框架最不好用的就是它的标签，除了 html 标签好用之外，其他的标签极其不好用，特别是 logic:iterator 远远没有 c:forEach 用起来舒服。Struts 2.x/WebWork 没用过。JBoss Seam
优点：
完全打破三层体系架构，借助于 JSF 采用两层结构，页面层和组件层，Seam 是按照业务逻辑来分层，而不是按照架构来分层。Seam 的最低版本是在 JDK 1.5 之上设计的，使用了很多 JDK 1.5 的新特性，大量地使用 Annotation，这种方式完全可以取代复杂的配置文件。就算是其中的日志组件也是采用变参实现的，这样我们就不用在页面上写 if(log.isDebugEnabled()) 了。采用严格 xml 格式的 xhtml JSF 页面，将 JSF 原本的配置分散到每个页面的 .page.xml 文件中，可以在里面写些：进入页面时需要执行的方法、有哪些参数需要传递的、页面如何导航等等。Seam 拥有完善权限模型，权限不仅可以在页面中表现，也可以通过 Annotation 在方法上限制该方法的执行权限。Seam/JSF 中的 Backing Bean 可以是普通的 Java Bean，也可以是 Session Bean，这样就可以让 Seam 工程不仅能运行在 EJB 容器中，也可以运行在 Servlet 容器中。Seam 中扩充了 Servlet 中的请求范围，增加了 Conversation、Process，而不是 Servlet 中的 application, session, request, page 四种。最常用的是 Conversation 这表示一个业务逻辑的作用范围，比 Session 小，比 Request 大。这种扩充完全是为了一整步骤的业务逻辑而定制的。想想看使用 Seam 可以使用 Seam Gen 或者是 JBoss Tools 的 Eclipse 插件产生某个表的增删改查分页功能，如果不涉及业务逻辑，而且使用默认的模板可以一行代码不用写，快速开发，诱人吧 ^_^以 JBoss Seam 为蓝本，其作者 Gavin King 提交的 JSR 299 -- WebBeans (Java Contexts and Dependency Injection) 已经被 JCP 采用，作为 Java EE 6 中的一部分。缺点：
学习难度相对于 SSH 大很多，学习资料相对较少，其中所使用的 JSF 不用说了，相对于 Hibernate，Seam 所使用的 JPA 也是需要一定阶段地学习才能灵活使用的。其中还有多如牛毛的 Annotation、双向注入、 WebBeans 等概念也是需要一定时间来掌握的。Seam 中所使用的页面组件框架，比如 Ajax4JSF, RichFaces 等等也是需要一定时间来掌握的。

JBoss Seam
对我很有吸引力

辛苦了，火龙果@菜菜宝宝。感慨：佩服！
火龙果@菜菜宝宝的技术功力应该比较扎实了。
我个人觉得struts1.X还是不错的，至少改变了我们把服务端代码写在jsp里面的编程习惯，可以说前进了比较重要的一步。
Seam 这个东西，脑子还没什么概念，看了你的介绍，感觉比较诱人。

嘿嘿，Seam 好是好，但是也很难学，起点要求远比 SSH 高很多，至少得先会用 JSF、JPA 什么的。

我补一下Struts 2吧，虽然我很久也没有用了。
优点：Struts MVC思想,WebWork架构的延续，不必按照1.x的规矩将FormBean与ActionBean，最重要的ActionBean不需要继承和实现任何框架接口。2.1.6中更改了原有的标注配置方式,离zero-configeration越来越近。
缺点：在分布式上，无法分隔前端与后端。

另，现在的Spring以远非以前的2.0.个人感觉Spring当前的DI方式慢慢的也优雅起来。@autowire等等标注的的使用不在是早期长篇堆积的xml。回到正题：spring的好就在于“好的支持”，google guice何等的优雅？但是还是没有spring如此的火热。　JMS，JMX，REST，SOAP等等方面的大部分框架都支持和Spring进行整合，另还有SpringSide这样的项目继续减少开发的复杂。Spring建立了一种架构的方式。
SSH可以没有Struts 可以没有Hibernate.可不能没有Spring.呵呵

SSH在开发大型项目的时候就会体现它的优势，若在中小型项目或小项目中使用SSH无异于自杀。

调试易

诚心请教：spring到底好在哪里？使用spring的理由是什么？

解决方案 »