使用JST與JSF訴Seam進行聯系

Question

有人能比較和對比這兩種解決方案嗎？ 我對Seam或JSF知之甚少，雖然我熟悉GWT的工作方式，非常喜歡它的理論。

主要關注點：

• 可擴展性/性能

• 跨瀏覽器兼容性

• 學習曲線

• 生產率

• WYSIWYG UI構建

• 在Java中盡可能多地編碼的能力（如果可能，我可以觸摸JS / HTML / CSS，但最好不要）

Answer 1

關於您的應用程序的客戶端開發，我們做出了同樣的決定。

我們決定選擇GWT，理由如下：

• 大多數開發都可以在java中完成。 由於我們在Java開發方面有很強的背景，這將為我們節省大量時間。
• 我們可以使用所有眾所周知和受歡迎的工具來實現，因為所有工具都是在java中完成的。
• 我們的應用程序將是一個類似桌面的單頁面Web應用程序，沒有完整的頁面刷新。 在這一點上，GWT似乎最適合這種需求（現在仍然如此）。
• 將大部分狀態推送給客戶並讓他做大部分耗費時間的處理都吸引了我們。 這樣，服務器可以處理大量的同時請求，並且只需要在服務器上同步狀態即可與服務器建立連接。
• 對單元測試 GWT代碼的支持很好，與MVP模式相結合甚至更好。
• 由於UiBinder的引入創建和樣式復雜的UI已經變得更容易和更快。

對您主要關注的問題：

• 跨瀏覽器兼容性主要由GWT本身負責。
• GWT Designer可以實現WYSIWYG（我必須說我從未使用過它;我喜歡自己構建UI ...）
• GWT非常快，因為渲染都是在客戶端完成的。
• 當你習慣了java時，生產力很高。
• 學習曲線主要取決於您使用的架構（MVP最初很復雜）。
• 您的應用程序將擴展，因為服務器無需昂貴的處理。

希望有所幫助。

（有關Seam選擇的一些考慮因素很快將來自@kraftan）。

Answer 2

關於應用程序的服務器端實現，在使用GWT而不是JSF時，必須考慮以下幾點（pro / con是主觀的，所以你應該決定）。

• 正如@ z00bs所提到的，使用GWT你會有一個類似app的桌面。 因此，您不會使用/需要Seam的頁面導航或頁面操作功能。
• 從GWT到服務器的所有請求都是短時間運行的。 這意味着，您的大多數組件都是ScopeType.EVENT或ScopeType.STATELESS並且您不需要/使用會話范圍。
• 使用GWT而不是JSF可以減少服務器上的負載，因為您擁有客戶端中的大部分狀態。
• 您不能將JSF / Seam生命周期與GWT一起使用。 例如，您在生命周期中丟失了模型驗證部分。 模型驗證只能通過使用實體管理器或手動觸發
• 在使用帶有GWT的Seam時，所有其他功能（例如安全性，郵件或EL）仍然有效。

由於Seam以其JSF支持而聞名，因此您應該考慮另一個框架，例如與GWT密切相關的Spring roo 。

Answer 3

通過在客戶端的內存中存儲長期持續交易（如購物車），Seam提供的會話范圍可以很容易地在GWT中替換。

Answer 4

都不是！ 如果你絕對沒有必要，請不要使用seam（或者jsf）！ java上有很多更好的Web技術。