什麼是製作圖形用戶界面的正確方法

Question

我正在研究一系列不同的軟件產品。它們已經很老了，所以我們正在重新考慮/改進它們。我的同事有抽象GUI的想法，讓它在自己的過程中運行，並通過套接字與程序的邏輯部分進行通信。這將允許我們在所有不同的應用程序中使用相同的GUI組件（保持相同的LAF）。所以我的問題是：這是創建GUI的有效做法嗎？保持與程序的其他部分相關的GUI會更好嗎？不同方法的優點和缺點是什麼，以及是否有其他方法來實現GUI？

謝謝

Answer 1

是的，這是一個非常有效的編寫GUI程序的方法。這大致是Web應用程序的工作原理 - UI（瀏覽器）通過套接字與業務邏輯服務器（Web服務器）通信。

這對於桌面應用程序來說有點不尋常，但它是完全可以接受的。這個解決方案的優點是，它可以讓你爲不同的平臺編寫多個富客戶端（例如移動應用，Windows應用，基於瀏覽器的應用等）。需要與後端交談。例如，它需要一種獲取對象和保存對象的方法，並且需要從後端接收UI需要更新的通知。

Answer 2

設計合理的服務和表示層應該完全沒問題。總結利弊，在我看來：

優點：不綁定物理邏輯

1. UI，所以邏輯層可以是遠程（爲多個客戶端，甚至 獨立BL服務器）。我們稱之爲「業務邏輯位置獨立性」。
2. 可以創建不同版本的GUI（不僅可以是圖形化的 - 可以將BL作爲服務公開，例如作爲提要或報告端點），「GUI平臺獨立性」以及SOA方法。
3. 可以在BL和GUI之間添加代理 - 用於安全和緩存目的。或負載平衡器在應用程序場之前。或者在重大BL更改後支持「舊」客戶端的適配器。 （「彈性和故障安全」）？
4. 部署可能在一定程度上更容易（修復UI中的錯誤不會影響BL層 - 只是二進制模塊無關的結果）
5. 能夠添加「脫機模式」到GUI。

缺點：

1. 你增加一個連接鏈路，這可能是又一個失敗點，以及一些精力應該花在用於測試。
2. GUI和BL之間的數據流量增加，可能還有更多的序列化工作。
3. 需要跟蹤通信協議更改和正確的協議版本維護。
4. （代理能力的負面）在GUI和BL之間進行中間人攻擊的可能性。

Answer 3

取決於應用類型。

桌面應用程序

這是有道理的，如果服務器可以在專用服務器上運行。如果服務器和GUI都要安裝在每個桌面上（對於大多數應用程序），這是沒有意義的。然後使用不同的項目/ dll來分離UI /業務邏輯。

Web應用程序

是。許多Web應用程序具有單獨的服務層和使用SOAP來進行GUI和服務層之間的通信。

套接字

使用香草插座今天很少是不錯的選擇。當有幾個優秀的IPC框架可用時，爲什麼要浪費能量/時間來構建自己的協議和實現。響應

更新評論

分而治之。將UI細分爲儘可能小的組件，以使其可重用。把這些組件放到一個單獨的項目/ dll中。示例組件可以是一個UserTable，它顯示所有用戶的列表（取決於接口IUserService的依賴關係）。

不要嘗試，因爲它註定要失敗的重用整個UI層。原因是，如果你試圖創建一個應該可配置和通用的UI，那麼你最終可能花費更多的時間，而不是使用可重用組件構建特定的UI。最後，您需要添加小的「黑客」來對通用UI層進行微小更改以適應每個應用程序。它將最終成爲一個emss。

重複使用上述組件爲每個應用程序構建特定的UI。