私は一連の異なるソフトウェア製品を開発中です。彼らはかなり古くなっているので、我々はそれらを再考/改善する過程にある。私の同僚は、GUIを抽象化し、独自のプロセスで実行し、ソケットを介してプログラムの論理部分と通信するという考えを持っていました。これにより、異なるアプリケーションすべてで同じGUIコンポーネントを使用することができます（同じLAFを維持する）。だから私の質問です：これはGUIを作成するための有効な練習ですか？ GUIを他のプログラムと結びつけておくほうがよいでしょうか？さまざまな方法の長所と短所は何ですか？GUIを実装するための他の方法はありますか？GUIを作成する適切な方法は何ですか
ありがとう
はい、これは完全に有効なGUIプログラムを作成する方法です。これは、おおまかに、Webアプリケーションがどのように機能するかです。UI（ブラウザ）は、ソケットを介してビジネスロジックサーバー（Webサーバー）と通信します。
デスクトップアプリケーションでは珍しいことですが、それはかなり受け入れられます。このソリューションの美しさは、さまざまなプラットフォーム（モバイルアプリ、Windowsアプリ、ブラウザベースのアプリなどを考えて）に複数のリッチクライアントを書くことができることです。
GUIだけでなく、バックエンドと話をする必要があります。たとえば、オブジェクトを取得しオブジェクトを保存し、UIが更新する必要があるバックエンドからの通知を受け取る方法が必要です。
サービスレイヤーとプレゼンテーションレイヤーが適切に設計され、完全に適切である必要があります。私の意見では長所と短所を要約すると：
長所：
短所：あなたは別のポイントに失敗し、いくつかの努力がそれをテストするために使われるべきではまだ可能性が1つの以上の接続リンクを追加している
アプリケーションの種類によって異なります。
デスクトップアプリケーション
サーバは、専用のサーバー上で実行することができればそれは理にかなっています。サーバーとGUIの両方を各デスクトップにインストールする場合（ほとんどのアプリケーション用）は意味がありません。次に、異なるプロジェクト/ dllを使用してUI /ビジネスロジックを分離します。
Webアプリケーション
はい。多くのWebアプリケーションでは、別々のサービスレイヤーがあり、GUIとサービスレイヤーの間の通信にSOAPを使用します。バニラソケットを使用して
ソケット
めったに今日は良い選択ではありません。いくつかの優れたIPCフレームワークが利用可能な場合に、独自のプロトコルと実装を構築するエネルギー/時間を無駄にするのはなぜですか。
分割統治をコメントに応答して
を更新。 UIをできるだけ小さなコンポーネントに分割して再利用できるようにします。これらのコンポーネントを別のプロジェクト/ dllに入れます。サンプルコンポーネントは、すべてのユーザのリストを提示するUserTable（インタフェースIUserServiceの依存関係を取る）であってもよい。
UIレイヤ全体が失敗するため、再利用しようとしないでください。その理由は、構成可能で一般的なUIを作成しようとすると、再利用可能なコンポーネントを使用して特定のUIを構築するよりも、その時間を費やすことになります。また、最終的には、各アプリケーションに合わせて汎用UIレイヤーに軽微な変更を加えるために、小さな「ハック」を追加する必要があります。それはemssで終わるでしょう。
代わりに上記のコンポーネントを再利用して、アプリケーションごとに特定のUIを構築します。
私たちのアプリケーションはすべてデスクトップアプリケーションです。私がしようとしているのは、GUIを抽象的なものにして、可能な限り構成可能なようにして、私たちのアプリケーションごとに（最小限のコーディングで）それを使用して、最終的にスイートとして組み合わせることです。したがって、BLをUIで分離し、IPCを使用して通信する以外に、UIを抽象化するという私の目標をどのように達成することを提案しますか？ – PTBG
私の更新を読んでください。 – jgauffin
サーバーとGUIが同じマシン上にあるとは意味がないと言います。どうして？それは珍しいことですが、それが理にかなっていないと言っても過言ではありません。 –
これは完全に有効な解決策です。多くのうまく設計されたウェブアプリにとって、それはまさに何が起こっているのかです。クライアントは何らかの種類のWebブラウザであり、ビジネスロジックは集中サーバー上で実行されます。 – Marvo