化繁為簡用Spring改進J2EE編程(圖)

2019-11-18 12:23:22

字體：大中小

來源：轉載

供稿：網友

　　摘要
　　
　　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。
　　　化繁為簡用Spring改進J2EE編程(圖)（圖一）

圖1. 接口可插性
　　
　　這個小例子表示一個溫度測量系統。幾個傳感器對象屬于不同的類型，但都實現了ProtocolAdapterIfc接口，因此在將它們插入TemperatureSensor對象時，它們是可互換的。在需要TemperatureSensor時，系統中的某個實體必須知道要生成并與該傳感器對象關聯的ProtocolAdapterIfc的具體類型。在本例中，該傳感器可基于命令行參數、數據庫中的行或通過屬性文件進行配置。本例還不足以造成挑戰或展示一個復雜框架，但它足以闡明IoC基礎。
　　
　　但是，想象一下：在一個相當復雜的應用程序中這種情況屢屢發生，而您還希望能動態地——至少要在外部——改變對象關聯。假設有一個DummyProtocolAdapter，它總是返回42這個值，使用它來進行測試。為什么不提供一個單個的統一框架？——讓開發人員能夠依靠該框架，以一種一致的、外部配置的方式建立類之間的關聯，并且不引起工廠單元素類(factory singleton classe)的異常增加。這聽起來可能沒什么大不了，但它要依靠于IoC的簡單性。
　　
　　我們使用一個TemperatureSensor類，它與一個實現ProtocolAdapterIfc接口的類有關聯。TemperatureSensor將使用該委托類來獲得溫度值。如UML圖所示，在實現ProtocolAdapterIfc并且隨后可用于該關聯的應用程序中有若干個類。我們將使用IoC框架（在本例中是Spring）來聲明要使用的ProtocolAdaperIfc的實現。Spring將在運行時建立關聯。我們先來看XML代碼，它將實例化TemperatureSensor對象并將一個ProtocolAdapterIfc實現與它關聯起來。該代碼如下所示：
　　<bean id="tempSensor"
　　class="yourco.project.sensor.TemperatureSensor">
　　<property name="sensorDelegate">
　　<ref bean="sensor"/>
　　</property>
　　</bean>
　　
　　
　　<bean id="sensor" class="yourco.project.comm.RS232Adapter"/>
　　
　　看了這些代碼之后，對于其目的就應該非常清楚了。我們配置Spring來實例化TemperatureSensor對象，并將其與RS232Adapter相關聯，作為實現ProtocolAdapterIfc接口的類。若想改變已經與TemperatureSensor關聯的實現，惟一需要更改的就是sensor bean標記中的class值。只要實現了ProtocolAdapterIfc接口，TemperatureSensor就不再關心關聯了什么。
　　
　　將這應用于應用程序相當簡單。我們必須先接入Spring框架，將它指向正確的配置文件，然后根據名稱向Spring索取tempSensor對象的實例。下面是相應的代碼：
　　
　　ClassPathXmlapplicationContext appContext =
　　new ClassPathXmlApplicationContext(
　　new String[]
　　{ "simpleSensor.xml" });
　　BeanFactory bf = (BeanFactory) appContext;
　　TemperatureSensor ts = (TemperatureSensor)
　　bf.getBean("tempSensor");
　　System.out.println("The temp is: "+
　　ts.getTemperature());
　　
　　可以看出，這些代碼并不是非常難。首先是啟動Spring并指定要使用的配置文件。接下來根據名稱（tempSensor）引用Bean。Spring使用這樣一種機制：基于simpleSensor.xml文件的描述創建該對象并與其他對象關聯。它用于注入依靠性——在本例中，通過將它作為一個參數傳遞給sensorDelegate()方法而實例化RS232Adapter對象并將其與TemperatureSensor對象關聯。
　　
　　比較起來，使用編程式java完成這一任務也不是很難。如下所示：
　　
　　TemperatureSensor ts2 = new TemperatureSensor();
　　ts2.setSensorDelegate(new RS232Adapter());
　　
　　純粹主義者或許會認為實際上這是更好的方法。代碼行數少，并且可讀性可能更強。確實如此，但這種方法的靈活性要小得多。
　　
　　可以隨意換入和換出不同層中不同對象的不同實現。例如，若Web層中的組件需要來自新業務對象的額外的功能，您只需將該業務對象與Web層對象相關聯，就像上面TemperatureSensor例子中的做法。它將被“注入”到Web對象中以隨時使用。
　　
　　能夠重新配置整個應用程序的結構，意味著可以輕松更改數據源。比如說，或者為不同的部署場景創建不同的配置文件，或者為測試場景創建更有用的、不同的配置文件。在測試場景中可能會注入實現接口的模擬對象，而不注入真正的對象。稍后我們將介紹一個這樣的例子。
　　
　　上面所述的例子可能是依靠注入的最簡單形式。利用相同的策略，我們不僅能夠關聯不同的類，還能夠在類中安裝屬性。諸如字符串、整數或浮點數之類的屬性，只要具有JavaBean樣式的存取器，就可以通過Spring配置文件將它們注入類中。我們還可以通過構造函數來創建對象和安裝屬性或bean引用。其語法只比通過屬性進行設置稍稍復雜一些。
　　
　　所有這一切都是利用一種靈活的聲明性配置完成的。無需更改代碼，建立依靠關聯的所有艱難任務都由Spring來完成。
　　
　　Spring--標準化的定位器模式
　　
　　我一直將服務定位器模式視作良好的J2EE規范的主要組成部分。對于不熟悉這一術語的人來說，可以這樣理解它：我們一般認為典型的J2EE應用程序由若干層組成。通常有Web層、服務層（EJB、JMS、WS、WLS控件）以及數據庫。一般來說，完成某一請求所需的“查找”服務中都包含了一些方法。Service Locator（服務定位器）模式認為，將這些方法包裝在某種隱藏了生成或查找給定服務的復雜性的工廠類中是一個好主意。這減少了JNDI或只會造成Web層操作類混亂的其他服務產品代碼的增加。在Spring出現以前，這通常是由經過考驗證實可靠的(tried-and-true)Singleton類來實現的。Singleton/Locator/Factory模式可以描繪為：
　　化繁為簡用Spring改進J2EE編程(圖)（圖二）

　　圖2. 定位器模式的順序圖
　　
　　這是對散布在整個Web控制器代碼中的增加的JNDI查找代碼的一個巨大改進。它被巧妙地隱藏在工廠內部的協作類中。我們可以使用Spring來改進這一術語。此外，該解決方案將適用于EJB、Web services、異步JMS調用，甚至還有基于WLS控件的服務。由Spring實現的這種定

上一篇：使用JMS在集群應用程序中分配任務(圖)

下一篇：J2ee核心技術：J2EE Frameworks介紹