Seam 敏捷開發與 JavaEE 經典分層架構__Java

Seam 敏捷開發與 JavaEE 經典分層架構

轉載請保留作者資訊：
Author: 88250
Blog: http:/blog.csdn.net/DL88250
MSN & Gmail & QQ: DL88250@gmail.com

本文簡要討論了兩個問題：Seam 與經典 JavaEE 分層架構的聯絡與問題；Seam 與 JSF 2.0 規範。這是一個系列的文章，將討論 Seam 架構用於實際開發的種種問題。

一、Seam 敏捷開發與 JavaEE 經典分層架構

在 Seam 中由於雙向注射(Binjection)的機制，允許我們可以減少層次的劃分，簡化設計、開發的複雜度。這也 Seam 架構的目標之一。不過，由於結合本項目的特徵（開源、規模較大），我決定還是基於經典的 JavaEE 分層去設計。
持久層 DAO
在 Seam 中，可以完全忽略持久層 DAO，在商務邏輯中直接進行實體管理。這樣做的好處是開發可以 更方便、更高效，壞處是重用少、難維護。特別是在這個開源項目中，分布式的團隊協作，優秀的設計 可以讓每個開發人員都更好的理解系統。結合 Seam 提供給我們的優勢，決定給常用的實體提供 DAO。 View 與組件
由於在 View 層可以使用 EL 直接調用某個 Seam 組件，所以會存在在各個層次中組件都可以在
View 中被使用。這樣做可能會導致混亂，是否應該建立一個 Facade 層來提供 View 需要的 組件呢。但是這樣做將會大大複雜整個系統的設計，尤其是將 Seam 提倡的快速開發思想完全拋棄。當然，好處就是 View 開發人員可以不用瞭解太多的邏輯組件，直接使用 Facade 層裡提供的組件。

綜合分析後，我覺得關於 DAO 是需要的，但 Facade 模式不應該放到基於 Seam 架構的設計中。原因就是 Seam 已經把 View 和邏輯“粘合得”很緊密了，我們不應該放棄 Seam 帶給我們的優勢。View 與商務邏輯 實現之間的介面無論如何都是要定義的，不應該為了一時方便而使用 Facade 模式。所以，Facade 模式的適用情境還需要進行深入思考和實踐。

二. Seam 與 JSF 2.0

當 前，JSF 2.0 的實現已經可以使用了，不過 Seam 還是只支援 JSF 1.2。JSF 2.0 中增強了 AJAX、預設使用 Facelets 作為視圖定義，還有一系列的新 JSF 組件與修改。這將對現有的一些 JSF 實現(RichFaces、MyFaces等)造成很大衝擊。不過這個也是沒有辦法的，現在該項目已經在開發中了，等JSF 2.0 正式 Release 的時候 Seam 應該會提供解決方案。