Spring Framework 的理解以及可維護性是否得以改善的思考
Spring的特性
提供了一種管理對象的方法
可以把中間層對象有效地組織起來
一個完美的框架
黏合劑
采用了分層結構
可以增量引入到項目中
有利於面向接口編程習慣的養成
目的之一是為了寫出易於測試的代碼
非侵入性
應用程序對Spring API的依賴可以減至最小限度
一致的數據訪問介面
一個輕量級的架構解決方案
對Spring的理解 Spring致力於使用POJOs來構建應用程序
由框架提供應用程序的基礎設施
將只含有業務邏輯的POJOs作為組件來管理
從而在應用程序中形成兩條相對獨立發展的平行線
並且在各自的抽象層面上延長了各自的生命周期
Spring的工作基礎是Ioc
Ioc將創建對象的職責從應用程序代碼剝離到了框架中
通常
中注入方式
setter 和 ctor參數
每個Bean定義被當作一個POJO（通過類名和JavaBean的初始屬性或構造方法參數兩種方式定義的Bean）
Spring的核心在org
springframework
beans
更高抽象層面是BeanFactory
BeanFactory是一個非常輕量級的容器
關於可維護性的思考 Spring之類的技術確實帶來了應用系統的可維護性的提高嗎？ Ioc
AOP之類的技術
本質上都是將原本位於應用程序代碼中
硬編碼
邏輯
剝離出來放到了配置文件中（或者其他形式）
主流聲音都是認為提高了應用程序的可維護性
但如果從以下方面觀察
結合項目實際經驗
個人感覺這些技術的應用大大降低了應用程序的可維護性
尤其是面對一個陌生的系統
或者項目人員變動頻繁的時候
中斷了應用程序的邏輯
使代碼變得不完整
不直觀
此時單從Source無法完全把握應用的所有行為
將原本應該代碼化的邏輯配置化
增加了出錯的機會以及額外的負擔
時光倒退
失去了IDE的支持
在目前IDE功能日益強大的時代
以往代碼重構等讓人頭痛的舉動越來越容易
而且IDE還提供了諸多強大的輔助功能
使得編程的門檻降低很多
通常來說
維護代碼要比維護配置文件
或者配置文件＋代碼的混合體要容易的多
調試階段不直觀
後期的bug對應階段
不容易判斷問題所在
性能問題
雖說硬件性能日新月異
但是性能也是在不經意間一點一點地流失的
從匯編到高級語言
到面向對象
到虛擬機
一直處於這樣的發展趨勢
From:http://tw.wingwit.com/Article/program/Java/ky/201311/28104.html
