Spring Framework的理解以及可维护性的思考

　　Spring Framework 的理解以及可维护性是否得以改善的思考
　
　　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对应阶段，不容易判断问题所在。 5. 性能问题。虽说硬件性能日新月异，但是性能也是在不经意间一点一点地流失的。从汇编到高级语言，到面向对象，到虚拟机，一直处于这样的发展趋势。