【转】spring框架是否提高了可维护性？首先Spring 是一个框架，使用Spring并不代表代码质量的提高，就像盖房子
【转】spring框架是否提高了可维护性？
首先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对应阶段，不容易判断问题所在。
[解决办法]
这个。。。
[解决办法]
发展 11111111
[解决办法]
用mvc还好，不过，ssh麻烦
现在很多都是注解了
[解决办法]
正在再次看SPRING官方文档，第一次接触SPRING文档时一扫而过，觉得很简单。。。觉得所谓的IOC就是把对象的依赖由硬编码改为XML配置，所谓的AOP就是在方法调用前后增加一层代理JDK自带的代理功能就可以了，可以想到的后面就直接PASS了不怎么学习SPRING了，所以很少用SPRING....像很多人说的，加入日志处理或者权限控制，我更喜欢在硬编码时就体现了。。。。。。。。。现在再次看它时才觉得主要是它的灵活性。。。。IOC只是核心，AOP是基于IOC，事务管理是基于AOP的。。。使用AOP或者事务这些功能的主要目的是为了让业务代码更加简洁，比如日志的记录，权限的控制，事务管理这些本就不是业务流程的功能让其解藕，还是很不错的
[解决办法]
没有一种适合于所有项目的框架
不同项目需求 不同开发规范和要求 就会使用不同的技术和框架
spring带来的更多是思想上的升华吧
[解决办法]
楼主说的也不是没有道理了，不过，毕竟，ssh的出现也有他的有点的。在我们做项目的过程中，我们也只是，选择最好的解决方案了。不是吗？
[解决办法]
[解决办法]...靠 我写之前还没人回复 写完这么多人回复了...
[解决办法][解决办法]同感！楼主说的太对了，spring害死人，用这个框架就是戴着镣铐跳舞。
个人也推崇jstl，简单明了。
[解决办法]------解决方案--------------------
[解决办法]。。。有几个人敢说他能把ssh用好，用精的。。。
还是那句，JB不正就别怪B歪
[解决办法]还是那句，JB不正就别怪B歪
说的好
[解决办法][解决办法]spring的结局就是下一个EJB。
当年EJB刚出来的时候，人人言必称EJB，似乎不懂ejb就是菜鸟似的，可是到如今，谁还用这垃圾东东。
现在很多人学spring，多数是冲声明式事务去的，真正用大量配置来实现java对象的ico，只有白痴才会那样教条。
配置文件好维护，还是代码好维护？其实谁都知道代码好维护，说配置文件好维护的人就是装B而已。
[解决办法]偶还是喜欢刚学jsp的时候一样，纯jsp。。神马ssh都不会。。JB不正就别怪B歪。。
[解决办法]我从未见过哪个项目用spring而提高了可维护性，甚至开发效率也没有提高。
java企业应用就是被这些一个个框架搞死的。
[解决办法]楼主说的有点偏激，何况有的朋友还说有学习的时间早用JSP做完了。我说明一下，你学习Servlet不需要时间么？没听过哪个处女怕疼一辈子不破除的，这本来就是疼一时爽一世的事嘛。当然必须有点过，但确实是，比起SSH带给我们的好处，学习的那点时间算什么。没有哪个程序员一辈子不学习的。
还有说到程序的健壮性，为什么用配置文件就不好呢？如果我们代码部署在服务器上了，我们就不能再编译了，敢问你怎么改代码，但是我们可以改配置文件啊。
框架是有一定弊端，但你不能否认它的优势所在。
[解决办法][解决办法]看过很多别人写的 Spring 代码，没感觉有什么可维护性，缺点倒是有不少，举几个例子：
1：为了接口而接口，有事没事就整一个接口。我想大多数人是先写实现类，再提取接口方法的吧？如果这样的话，那接口的存在有何意义？这样的接口有扩展性么？
接口一般是在实现之前定义好的，一经定义后，在很长的一个周期内是不允许更改的！如果能做到这一点的话，那接口是有存在价值的，否则一无事处！
2：结构层次变得非常复杂，分层过来细致，使得调用层次增多，有些层次中基本上就是些方法的委托调用，这样导致开发效率大大地降低。加之接口的滥用，如果某一逻辑需要更改，势必会造成大量的代码改动！
开源产品也适用于这句话：产品做得好，不如广告做得好！
比 Struts, Spring, Hiberate 好的开源框架有很多，在这所谓“SSH”框架的年代下，是有多少人能知道呢？
[解决办法][解决办法][解决办法]补充一下。
多数项目刚开始的时候，往往项目成员对各种框架的掌握程度不一，而项目负责人总要选用统一的框架，结果迫使不懂这个框架的成员学框架，一开始就浪费了大量时间。再由于上面所述的各种原因，开发过程又总是十分缓慢。
我回顾之前的开发经历，发现一个现象：jsp+servclet的开发效率远远高于SSH，可维护性更高于SSH。
2003年开发的一个工作流项目，纯jsp+servlet开发，4个月开发完毕，其后多次重构和大的改动，越来越完善。
而其后的几个SSH做的项目，严重拖延、效率低下，代码臃肿不堪，几乎把程序员折磨疯了。
[解决办法]java开源框架的出现也许本来就是一种错误，对java企业应用的开发造成了致命的伤害。
同时用过.net和java的人都知道，java框架的可怕
[解决办法]我就不信了，你们的水平足矣够批判这些开源架构资格的？，无语..........
[解决办法]有谁真正因为用SSH而提高了系统的开发效率和可维护性
------解决方案--------------------
[解决办法]...看来我被无视是惯性的..
学一个框架不难 难的是熟练使用一个框架 我不提倡盲目用什么SSH(也不知道谁起的破名)
存在既有意义 你光看缺点不看不看产生缺点的原因我也没什么办法 我试图跟别人解释在页面用标签的好处 他最后就坚持住"我用服务端脚本也能完成"这个理由跟我死磕 我跟别人讲用Spring的好处 居然又出现了"用起来太麻烦"的理由 做了什么事情肯定有后果 不要总是看着坏的后果
当然 我也不赞成盲目的去用什么框架 至少在用之前需要明白自己为什么这么用
就像19L说的
[解决办法]而且居然看到有人觉得说配置文件好维护的人是装逼的行为 我好奇的问下 你的意思是把代码写到配置文件里不好维护对吧?
[解决办法]我觉得，SSH中,struts这种东西是最好用的，也最适用的，用起来也简单，完全符合MVC思想；
hibernate这种东西，中小系统可以用用，数据关系不很复杂，数据量百万级以下可以用用；
Spring这种东西吧，关系复杂，兼容性要求高的用用。中小系统或是专业系统还是不要用了吧。
jsp + servlet肯定不是最好的，至少开发效率低了不少。
对我来说有struts就够了，spring从来没用过。
求指正！
[解决办法][解决办法][解决办法][解决办法][解决办法][解决办法][解决办法][解决办法]spring 的mvc 你们谁用过 好用不？
[解决办法][解决办法]个人感觉还是用配置文件好维护些，至少所有的配置文件都在一起，好找，注解遍地开花， 到处找，让后面加入的童鞋们上哪找去……
[解决办法][解决办法]------解决方案--------------------
存在即合理。
存在肯定有存在的价值，使用的时候是看项目适用不适用！
很小的系统我们完全可以jsp+servlet+jdbc。
很大的系统你这么写会封掉。银行的系统肯定需要框架来分层，业务庞大，使用了框架规范后开发人员也可以有标准。
[解决办法]SSH很实用、虽然在性能上有一点点的缺陷，但也在可接受范围之内。SSH帮我们省了很多时间很多事、开发人员不需要自己编码去实现一整套的MVC模式。对于后期的维护、扩展都非常的简便。Spring配置都是死的，可以照搬的、稍微改下就可以了。又不用每次都是自己全敲。Spring是IOC和AOP。IOC就是将类与类之间的依赖关系写在配置文件中，降低类与类之间的耦合度，将这就不是像关在笼子里。而是将笼子打开了。
[解决办法]对于低吞吐量的小系统，执行效率要求不高的系统，频繁改动功能并重新部署的系统，
用SSH，在有比较好的设计的前提下，还是挺有效率的。
高吞吐量，多服务器，高并发的大系统，用SSH框架那是找死呢。
[解决办法][解决办法]路过，学习一下！
[解决办法][解决办法]
