利用Spring架構改進J2EE編程

摘要

J2EE編程正在變得越來越複雜。J2EE已經發展為一個API、複雜化的編程和配置的複雜網路。為了應對這種複雜性，新的架構和方法不斷湧現。這些架構高度依賴於一個稱為IoC（Inversion of Control，反向控制）的概念。本文將探討這種方法的一些特性和優點，因為這種方法與J2EE編程相關，而且可以使J2EE編程變得更輕鬆。

簡介

馬克·吐溫的一句話常被引用：“……關於我死亡的報道是一種誇張。”現在已經出現了很多關於.Net的流言，以及認為J2EE API的複雜性無法克服和EJB作為一種組件架構即將滅亡的流行極客(geek)文化。從學術或者只是想像的立場來看，這沒什麼大不了的，但事實是J2EE/EJB API已經經曆了一場達爾文式的進化。具有DCOM或CORBA項目經驗的讀者會明白我的意思。過去，人們都樂於聽聞EJB組件模型的美好前景。實際情況是，人們在與J2EE相關的各個方面都投入巨大。宣布拋棄以前的所有工作並重新組織，這種想法看起來也許有理，但是它並沒有建立在良好的業務洞察力之上。EJB繼續發展，而術語、實踐和架構也隨之湧現(spring up)，它們彌補了J2EE API的不足。我說的不是“Spring出現(up)”，對吧？

我是一名顧問，職責是協助構建大型的分布式應用程式，而且通常是J2EE應用程式。因此，我有機會親曆許多項目的整個生命週期。另外我還能夠將我從一個剛剛完成的項目中剛剛學到的東西直接帶入一個全新的項目。從某種意義上說我的“自然選擇”過程加快了。我可以說最近Spring（更具體地說就是IoC，即反向控制）已經越來越多地融入到我的項目中了。在本文中，我將從支援或增強J2EE項目的角度來探討Spring。更確切地講，Spring架構能夠標準化許多J2EE最佳實務，還能同類化(homogenize)許多無處不在的J2EE模式。接下來我們將瀏覽Spring龐大體系中的一小部分內容，重點介紹（依我淺見）能夠協助改進J2EE應用程式的功能。

IoC簡介

一般來說，IoC是一種管理類之間關聯的技術。沒錯，就這麼簡單！任何人都不是孤立的，對於各個對象來說也是如此。應用程式中的對象是相互依賴的。通過編程方式來表現這種依賴性通常既冗長又容易出錯。好的IoC架構將聲明式地（通過一個XML設定檔）而不是編程式地（這種方式的可靠性較差）——串聯起應用程式之間的相互依賴性。

自由使用介面是IoC開發的一個主要方針。介面編程大大提高了應用程式的靈活性，從而增強了聲明式的關聯。介面實現是通過IoC配置在運行時聲明的，這樣就能夠在不影響或少影響實際應用程式代碼的情況下“重建(rewire)”關聯。這在各種IoC架構中是反覆提及的一個主題，一般而言，也是應該遵循的良好實踐。

一個小例子

我喜歡通過例子來更快地理解概念。下面就是運用了IoC的一組例子；您將看到，這些例子的複雜性是逐遞增的。大多數人在一開始使用IoC容器時都是利用其依賴注入(inject dependency)功能——即，聲明式地將對象關聯起來。利用IoC有助於建立更整潔的代碼，如有必要重建對象之間的關聯，一般來說對於這些代碼也會更靈活、更容易。IoC的優點遠不止依賴注入，而其擴充功能確是以依賴注入程式為起點的。

我們將從構建簡單的依賴注入例子開始。第一個例子用於闡明已經提及的兩個概念。第一個概念是IoC在運行時構建和關聯對象的能力，第二個是與介面編碼相結合而產生的靈活性。首先假定架構師遞交了圖1所示的UML。

圖1：介面可插性