Java EE/J2EE物件導向編程之道

OO思維

經常看到不少人抱怨Java EE/J2EE中配置太複雜，煩瑣，不簡單易學，其實所謂簡單易學是取決於你是否有OO思維方式。

表現層的介面表單中通常是一些離散資料，也就是單個欄位資料，通過Struts等架構提供ActionForm以及標籤庫，將這些單個欄位資料封裝起來和業務層的Domain Model進行了映射，因此，表現層的主要編程工作就是映射配置。

持久層是將Domain Model對象儲存到資料庫中，過去使用JDBC，我們要逐個開啟這些Model對象，然後每個欄位逐個儲存到資料庫中，如果說表現層架構是實現離散資料封裝，那麼持久層實現的是反方向：拆封。Hibernate是一個持久層O/R mapping架構，也就是在對象和關聯式資料庫之間進行映射的架構，EJB的CMP也是類似道理，因此，持久層的主要編程工作也是映射配置。

表現層和持久層這種配置工作就如同打包郵寄一樣：你首先要將你的單件用一個箱子封裝起來，達到目的地，這個箱子被開啟，單件被逐步取出。表現層和持久層這樣做的目的是保證中間業務層完全物件導向，他們都是和一個個對象打交道，而不是單件資料欄位。

在一個真正物件導向的系統中，表現層和持久層主要工作就是配置，而且是映射mapping的配置。下面的問題就是：如何解決映射配置簡單而且易用，如果擁有正確的指導配置的思維，那麼配置工作就容易簡單多，否則，就倍感配置複雜。

其實那些感覺Java配置複雜的人其實他並沒有完整的OO思維。為什麼這麼說呢?以ORM(Hibernate)配置簡易方式說明：

配置的簡要之道

首先，配置是映射配置，顧名思義，也就是在兩者之間做協調，牽線搭橋，說白了，就是做紅娘，但和做紅娘又有些區別，做紅娘可以要求雙方做些改變，互相遷就，但是做映射配置，則不能這樣，因為那樣做就可能做出和需求要求不一樣的東西。

以持久層映射配置來說：雙方是指Domain Model對象和關係資料表，如果感覺在兩者之間配置映射很困難，雙方做些改變，但是有可能 需求不答應，你一旦為協調而作出的改變可能偏離需求實現的目標，最後作出的系統面貌全非，根本不是客戶所需要的。

那麼怎麼辦?很顯然，緊扣需求，反映需求的那一方堅決不要變動，那麼Domain Model和關係資料表哪一方反映需求呢?按照OO分析，當然 是Domain Model，Model對象我們是依據Evans Model等模型驅動設計MDD概念設計出來，他們是需求的代表。

很顯然，我們的映射配置必須順著Model對象這個思維來配，對於名詞式的Model，關聯無外乎是其主要關係，當然還有繼承，因此，象Hibernate 這些映射配置文法也是面向這些主要對象關係的。

表現層配置也是同樣的道理，需要將Domain Model配置成介面表單，在實際中，我們有可能採取的是通過介面收集需求，因此，這個映射配置過程也是考驗Model對象是否提煉正確與否，有可能發現Model不能實現一些介面需求功能，這時反過來必須修改我們的Model，而不是僅僅在表現層這個技術層面做些補救措施就糊弄過去。

Java EE/J2EE系統開發過程 敏捷的迭代是必然的。沒有一個天才能夠一步到位提煉出兼顧介面和資料表以及需求的統一模型出來。

總之，完成一個真正物件導向的Java EE/J2EE系統，必須抓住領域建模和具體架構熟練配置兩點，只有這樣才能保證Java項目成功實施。最關鍵的是提煉出反映出業務系統的領域模型：Domain Model，完成業務建模後，就是依賴Struts/Hibernate等配置分配將Model 映射到介面和資料庫，其實就是將業務模型移植到電腦領域並能夠正確運行。