Seam應用程序體系結構

Question

我需要在Seam中實現相當大的系統。我正在考慮設計架構的方式。如果使用頁面控制器或應用程序控制器或前端控制器或每一個都是好的。如果使用後端bean有幫助，或者沒有必要這樣做。如果您有任何建議或鏈接到有用的文章，我將不勝感激。

非常感謝！

丹尼爾Mikucki

Answer 1

如果你需要學習很多關於煤層的一個項目，我建議你在Seam In Action書，這是最好的話題。

爲了回答你的問題，我個人更喜歡在Seam中使用pull-MVC風格，在那裏你引用視圖模板中的數據，Seam根據需要使用@Factory方法來初始化數據。然而，在Seam中有多種方式來完成它，因此值得首先閱讀替代方案，因此本書建議值得一讀。

或者，先建幾個Seam應用扔掉你試圖建立一個「正確」的:)

Answer 2

丹尼爾，

這是很好的做法是使用一個前端控制器，大多數人不是活得前不知道那種設計模式。

這是一個非常好的設計模式，因爲它確保您通過一個入口點訪問應用程序。您可以使用較少的配置來監控所有進入和運行的情況。由於存在單個入口點，因此可以減少可能的代碼複製量。除了維護代碼更少以外，代碼應該更容易遵循，因爲只有一種方法。然後，您可以輕鬆地遵循應用程序的執行流程。

不幸的是，Seam並沒有真正的前端控制器模式。我沒有花費盡可能多的時間，因爲我想開發自己的產品，但安全和審計能力是我的首要關注點。

就頁面/應用程序控制器而言，在Seam中，您有更多可用的上下文或範圍。事件，頁面，對話，會話，應用程序，以命名他們中的大多數。

如果您正在開發控制器或在Seam中進行頁面操作，則大部分時間都是基於事件的。這是最短的範圍。如果您有頁面流，則可以使用會話範圍的組件。

看看源代碼中的例子。你可以用很少的代碼做很多事情，這真是太神奇了，但同時還有很多事情要做，可能需要一段時間才能完成。

大多數地方遵循的n層設計並不一定適用於此。對於我的大部分頁面，我定義了一個將在XML中使用的查詢（實體查詢），然後將其注入到我的頁面操作中並在那裏調用它。因此，您最終只需一個頁面操作，查詢和實體類，而不是擁有控制器，服務，dao和實體類。在大多數情況下，您可以切掉服務和dao圖層。

您對服務的整個定義可能也會發生變化。對我而言，服務是服務提供者，例如通知，安全（審計），異常處理等等。所有這些服務都在後臺運行，並且不受特定的http請求限制。

沃爾特

Answer 3

丹尼爾，

我已經使用每頁一個控制器，一個服務，每一個實體道。

• 用例邏輯是在控制器
• 實體具體的業務邏輯是在實體服務。
• 操作其跨越多個實體，你可以創建一個門面的服務 - 這是它坐落

控制器與實體部門之間雖然上面是一個很好的和實用的方法，最好：

• 你能打破將來自控制器的任何非MVC代碼轉換爲它自己的服務類，即。每頁1個服務級別
• 您只能通過實體服務訪問實體dao。

這裏的控制將如何流動：

理想： UI - > PageController.java - > PageService.java - > EntityService.java - > EntityDao.java

實際上，你可以修剪幾層： UI - > PageController.java - > EntityService.java

或者對於觸及多個實體的操作： UI - > PageController.java - > Facade.java - > Entity1Service.java，Entity2Service.java

PageController.java將是一個Seam @Component和您的用戶界面，你可以參考它： #{pageController}和拉取數據從視圖。

在體系結構中，最重要的是你如何在堆棧中分層，避免了層之間的循環依賴。例如，實體服務不應該引用控制器等。

另一個重要的事情是要在整個應用程序中保持一致。如果可以使代碼生成器在整個應用程序中保持一致，那麼它確實爲大型項目付出了代價。如果您對代碼生成感興趣，請查看Clickframes（Clickframes爲Seam應用程序生成啓動代碼，並提供完整的JPA/Valdiation /安全支持，然後您可以對其進行修改）。如果感興趣，請參閱使用Clickframes構建的Seam demo。