首先Spring 是一个框架，使用Spring并不代表代码质量的提高，就像盖房子选择用上海的地皮还是北京的地皮一样，房子质量与土地所在的城市无关，与房子的具体设计方案和选料有关。
使用Spring 等框架可以简化很多基础性的工作，配置好后可以方便构建业务应用。框架使用多了会有局限的感觉，像小鸟被套在笼子里，无法飞出去，虽然在笼子里面吃喝不愁。目前编程的门槛越来越低，诸多开源框架广泛传播，几乎没有什么技术门槛，会配置就会编程，而一个好的DBA对软件性能会有很大提高，软件的核心逻辑最终会转移到对数据库的操作上，而且对目前从事的工作来讲，感觉技术的瓶颈越来越多的局限在对数据库的操作上，下一步要认真提高下了。Spring的优势不言而喻： 1. 提供了一种管理对象的方法，可以把中间层对象有效地组织起来。一个完美的框架“黏合剂”。 2. 采用了分层结构，可以增量引入到项目中。 3. 有利于面向接口编程习惯的养成。 4. 目的之一是为了写出易于测试的代码。 5. 非侵入性，应用程序对Spring API的依赖可以减至最小限度。 6. 一致的数据访问介面。 6. 一个轻量级的架构解决方案。 对Spring的理解 Spring致力于使用POJOs来构建应用程序。由框架提供应用程序的基础设施，将只含有业务逻辑的POJOs作为组件来管理。从而在应用程序中形成两条相对独立发展的平行线，并且在各自的抽象层面上延长了各自的生命周期。 Spring的工作基础是Ioc。Ioc将创建对象的职责从应用程序代码剥离到了框架中，通常2中注入方式：setter 和 ctor参数。 每个Bean定义被当作一个POJO(通过类名和JavaBean的初始属性或构造方法参数两种方式定义的Bean)。 Spring的核心在org.springframework.beans，更高抽象层面是BeanFactory. BeanFactory是一个非常轻量级的容器。 关于可维护性的思考 Spring之类的技术确实带来了应用系统的可维护性的提高吗? Ioc， AOP之类的技术，本质上都是将原本位于应用程序代码中"硬编码"逻辑，剥离出来放到了配置文件中(或者其他形式)。主流声音都是认为提高了应用程序的可维护性。 但如果从以下方面观察，结合项目实际经验，个人感觉这些技术的应用大大降低了应用程序的可维护性，尤其是面对一个陌生的系统，或者项目人员变动频繁的时候。 1. 中断了应用程序的逻辑，使代码变得不完整，不直观。此时单从Source无法完全把握应用的所有行为。 2. 将原本应该代码化的逻辑配置化，增加了出错的机会以及额外的负担。 3. 时光倒退，失去了IDE的支持。在目前IDE功能日益强大的时代，以往代码重构等让人头痛的举动越来越容易。而且IDE还提供了诸多强大的辅助功能，使得编程的门槛降低很多。通常来说，维护代码要比维护配置文件，或者配置文件+代码的混合体要容易的多。 4. 调试阶段不直观，后期的bug对应阶段，不容易判断问题所在。
使用Spring 等框架可以简化很多基础性的工作，配置好后可以方便构建业务应用。框架使用多了会有局限的感觉，像小鸟被套在笼子里，无法飞出去，虽然在笼子里面吃喝不愁。目前编程的门槛越来越低，诸多开源框架广泛传播，几乎没有什么技术门槛，会配置就会编程，而一个好的DBA对软件性能会有很大提高，软件的核心逻辑最终会转移到对数据库的操作上，而且对目前从事的工作来讲，感觉技术的瓶颈越来越多的局限在对数据库的操作上，下一步要认真提高下了。Spring的优势不言而喻： 1. 提供了一种管理对象的方法，可以把中间层对象有效地组织起来。一个完美的框架“黏合剂”。 2. 采用了分层结构，可以增量引入到项目中。 3. 有利于面向接口编程习惯的养成。 4. 目的之一是为了写出易于测试的代码。 5. 非侵入性，应用程序对Spring API的依赖可以减至最小限度。 6. 一致的数据访问介面。 6. 一个轻量级的架构解决方案。 对Spring的理解 Spring致力于使用POJOs来构建应用程序。由框架提供应用程序的基础设施，将只含有业务逻辑的POJOs作为组件来管理。从而在应用程序中形成两条相对独立发展的平行线，并且在各自的抽象层面上延长了各自的生命周期。 Spring的工作基础是Ioc。Ioc将创建对象的职责从应用程序代码剥离到了框架中，通常2中注入方式：setter 和 ctor参数。 每个Bean定义被当作一个POJO(通过类名和JavaBean的初始属性或构造方法参数两种方式定义的Bean)。 Spring的核心在org.springframework.beans，更高抽象层面是BeanFactory. BeanFactory是一个非常轻量级的容器。 关于可维护性的思考 Spring之类的技术确实带来了应用系统的可维护性的提高吗? Ioc， AOP之类的技术，本质上都是将原本位于应用程序代码中"硬编码"逻辑，剥离出来放到了配置文件中(或者其他形式)。主流声音都是认为提高了应用程序的可维护性。 但如果从以下方面观察，结合项目实际经验，个人感觉这些技术的应用大大降低了应用程序的可维护性，尤其是面对一个陌生的系统，或者项目人员变动频繁的时候。 1. 中断了应用程序的逻辑，使代码变得不完整，不直观。此时单从Source无法完全把握应用的所有行为。 2. 将原本应该代码化的逻辑配置化，增加了出错的机会以及额外的负担。 3. 时光倒退，失去了IDE的支持。在目前IDE功能日益强大的时代，以往代码重构等让人头痛的举动越来越容易。而且IDE还提供了诸多强大的辅助功能，使得编程的门槛降低很多。通常来说，维护代码要比维护配置文件，或者配置文件+代码的混合体要容易的多。 4. 调试阶段不直观，后期的bug对应阶段，不容易判断问题所在。
1. 增加了学习的时间，因为一个团队不是每个人都懂这些东西，要让每个人都学会需要较长的时间
2. 配置文件太多太杂太庞大，稍有不慎就出一些编译阶段发现不了的错误，查找十分麻烦
3. 在jsp+servlet之上包装了一层又一层，导致开发人员稍微底层一点的问题就完蛋，现在的java程序员谁还记得HTTP规范？有的问题，只要在http头写一行代码就解决的问题，面对框架愣是一筹莫展。也许回归jsp+servlet是一个正确的选择。
struts架构太复杂，可以不用，一定不想让页面出现java代码，用jstl也不错
更可怕的是，现在IDE的代码重构功能十分强大，程序员有一种本能的冲动去重构代码，导致配置文件的维护更加复杂。
问题是，有谁真正因为用SSH而提高了系统的开发效率和可维护性？加上学习成本在内
写了这么多...一个一个说吧你的房子比喻不太恰当 简单的说 住房子的是你 使用房子的是你 但是盖房子或者拆迁房子甚至于生活中的一些小事(房屋装修,修马桶)不是你应该做的 Spring的作用就是负责管理对象的依存关系以及生命后期 让你在你的房子里享受你的生活的时候不必为了这个房子的任何事情苦恼(房租不算..)..没感觉什么编程门槛低 也没觉得框架随便配置几个文件就能搭建一个应用程序(你说的是grails?还是什么其他的快餐框架..) 那种东西我不知道算不算是框架 我管他叫平台..至于你提出的反驳 我也简单的说下1.单从Source是看不出来这段代码在实际运行中执行的全部操作..那么为啥要单看Source..
一些通用功能做AOP还是可以理解的 比如事务 但是具体的业务就不要写到AOP里去吧..2.仅仅是通过配置文件管理依赖关系 跟逻辑有啥关系?选择不同的实现类只需要更改下配置文件 比原来改代码更轻松些吧3.关于第二点...我再补充下 有人认为将配置信息分离出来会导致维护成本提高 我感觉这种比喻就是觉得做菜太麻烦 干脆生吃比较轻松.. 分离出来又不是没有好处 比如你在部署之后发觉当前实现有些不妥当 你在这个时候直接可以通过更改配置文件切换到另外一个实现去 而不是更改源代码再编译一次..况且也不一定都得用XMl 你可以用注解嘛..4.没明白调试BUG跟Spring有啥关系
有学那么多配置的时间，用jsp—+servlet早把项目做得更好了。
至少现在eclipse IDE功能很强，代码逻辑关系，只敲一个功能键就显示清楚了。用框架反而看不出来了
你就有点逗了。
JSTL 跟 spring 有啥关系？ 框架有框架的好处，原生态有原生态的好处。
说的好
何况框架一两年一翻新，等你学好用精，又过时了。
这就是为什么java程序员总是疲于奔命，C程序员能形成长久技术积累的原因。
当年EJB刚出来的时候，人人言必称EJB，似乎不懂ejb就是菜鸟似的，可是到如今，谁还用这垃圾东东。
现在很多人学spring，多数是冲声明式事务去的，真正用大量配置来实现java对象的ico，只有白痴才会那样教条。配置文件好维护，还是代码好维护？其实谁都知道代码好维护，说配置文件好维护的人就是装B而已。
java企业应用就是被这些一个个框架搞死的。
还有说到程序的健壮性，为什么用配置文件就不好呢？如果我们代码部署在服务器上了，我们就不能再编译了，敢问你怎么改代码，但是我们可以改配置文件啊。
框架是有一定弊端，但你不能否认它的优势所在。
理论上改配置文件不需要重新编译部署。但实践中没发现哪个项目的维护工作是不改代码，只靠改配置文件解决的，而且重新编译部署不需要花多少时间。
其实框架的弊端已经被越来越多的人认识。
河东河西轮流转，EJB 3 之前是重量级的，但是现在轮到 SSH 了，SSH 是越来越重，配置越来越复杂，而 EJB 则是越来越简单，配置是越来越少。
其实框架的还有更加严重的后果：导致程序员付出了大量的无效劳动。
由于框架层出不穷，花样几乎月月翻新。程序员刚学完一个框架，很可能就又过时了，以前的努力全部归零，又要学新的框架。这就是为什么C程序员能够天天进步，形成长久的技术积累；而java程序员却不断地狗熊掰苞谷，掰一个扔一个，十年下来等于一年的积累。现在很多项目已经是纯粹为了框架而框架。
1. 本来structs的目的是为了摆脱jsp页面上的java代码，但页面上密密麻麻的struts标签多数情况下比java代码还难以维护和理解，还要为formBean、action、service做对应；还要维护那个编译期间根本不可能发现错误的庞大配置文件。个人认为struts实际上已经成为拖慢开发效率的一大拦路虎。
2. spring也好不到哪里去，看它一天天膨胀的配置文件，哪个程序员不是小心翼翼地改动，生怕改错一小点就导致崩溃。spring MVC的页面标签库比struts还恶心。
多数项目刚开始的时候，往往项目成员对各种框架的掌握程度不一，而项目负责人总要选用统一的框架，结果迫使不懂这个框架的成员学框架，一开始就浪费了大量时间。再由于上面所述的各种原因，开发过程又总是十分缓慢。
我回顾之前的开发经历，发现一个现象：jsp+servclet的开发效率远远高于SSH，可维护性更高于SSH。
2003年开发的一个工作流项目，纯jsp+servlet开发，4个月开发完毕，其后多次重构和大的改动，越来越完善。
而其后的几个SSH做的项目，严重拖延、效率低下，代码臃肿不堪，几乎把程序员折磨疯了。
java开源框架的出现也许本来就是一种错误，对java企业应用的开发造成了致命的伤害。
同时用过.net和java的人都知道，java框架的可怕
看国外sourcecode论坛上 ，对ssh的质疑声不断。而国内却一片崇拜声音，生怕提出质疑被人讥笑。
其原因无他，几千年来的传统。
存在既有意义 你光看缺点不看不看产生缺点的原因我也没什么办法 我试图跟别人解释在页面用标签的好处 他最后就坚持住"我用服务端脚本也能完成"这个理由跟我死磕 我跟别人讲用Spring的好处 居然又出现了"用起来太麻烦"的理由 做了什么事情肯定有后果 不要总是看着坏的后果
当然 我也不赞成盲目的去用什么框架 至少在用之前需要明白自己为什么这么用
就像19L说的
对我来说有struts就够了，spring从来没用过。求指正！
代码错了，有IDE给你指出来。配置文件里的类名和方法名拼写错了，谁会告诉你？
再者，用重构功能改动类名和方法名的时候，你就知道spring的配置文件有多恶心了
到底是代码编写阶段就知道错在哪方便，还是在运行时出错，再去分析log文件费尽功夫找到错误方便？
我不用spring，重构的时候，自动把相关引用都改过来了。用了spring却无法自动更改了，只能手工更改，增加了错误的概率
你所谓的自动把相关引用都改过来了是咋改的？就改一个字?
用SSH，在有比较好的设计的前提下，还是挺有效率的。高吞吐量，多服务器，高并发的大系统，用SSH框架那是找死呢。
你那么推崇这个框架，你敢说心里话你用这个东西提高了开发效率吗？提高了可维护性了吗？
至于strus标签库，连struts开发小组都不赞成了，国内一些装B公司还要它当成页面规范。