プログラムのモジュールを分離して、相互に通信したいと考えています。それらは同じコンピューター上にある可能性がありますが、異なるコンピューター上にある可能性があります。
私は2つの方法を検討していました：
したがって、ハッシュテーブルとクラスに要約されます。
「疎結合」だと思うなら、ハッシュテーブルを好みます。一方のモジュールを更新するのは簡単で、もう一方のモジュールを更新せずに、新しい追加パラメーターを hastable に含めます。
次に、クラスを使用して、実行時ではなくコンパイル時の型チェックを行います。
誰かが以前にこれに取り組み、これについて提案がありますか?
ありがとう！
編集：元の質問に最も関連する回答にポイントを与えましたが、最も支持された回答ではありません
システムにIPC (Inter-Process Communication)を組み込みたいだけのようです。
.NET (3.0 以降) でこれを実現する最善の方法は、Windows Communication Foundation (WCF)を使用することです。WCF は、さまざまな異なる方法 (トランスポート) でプログラム間を共通の方法で通信するために Microsoft によって開発された汎用フレームワークです。
おそらく効率と堅牢性のために名前付きパイプを使用したいと思うでしょうが、TCP や HTTP (この MSDN の記事を参照) など、他にも多数のトランスポートを利用できます。バイナリからXML から JSON へ。
分散システムの設計では、この種の問題に直面する傾向があります。これは、メッセージの形式が XML またはその他の明確に定義された形式である Web サービス (パラメーターと戻り値の型を定義する WSDL) メッセージング システムで表示されます。クライアントとサーバーの結合を制御するという問題は、すべての場合に残ります。
ハッシュ テーブルはどうなりますか? リクエストに「NAME」と「PHONE-NUMBER」が含まれていて、「LANDLINE-NUMBER」と「CELL-NUMBER」を区別する必要があることに突然気付いたとします。ハッシュ テーブル エントリを変更して新しい値を使用するだけの場合は、サーバーも同時に変更する必要があります。この時点で、1 つのクライアントと 1 つのサーバーだけではなく、おそらく何らかの取引所またはブローカー システム、多くのチームによって実装された多くのクライアント、多くのチームによって実装された多くのサーバーを扱っているとします。それらすべてに同時に新しいメッセージ形式にアップグレードするように依頼するのは大変な作業です。
したがって、「PHONE-NUMBER」を保持し、新しいフィールドを追加するなど、追加の変更などの後方互換性のあるソリューションを探す傾向があります。サーバーは、古い形式または新しい形式のメッセージを許容するようになりました。
ディストリビューション テクノロジが異なれば、下位互換性に対する組み込みの許容度も異なります。シリアル化されたクラスを扱う場合、古いバージョンと新しいバージョンを扱うことができますか? WSDL を処理する場合、メッセージ パーサーは付加的な変更を許容しますか。
プロセスは次のとおりです。
1)。クライアントとサーバーの間に単純な関係がありますか。たとえば、両方をコーディングして制御し、リリース サイクルを自由に指示できますか。「いいえ」の場合は、柔軟性を重視し、ハッシュ テーブルまたは XML を使用します。
2)。制御できている場合でも、シリアライゼーション フレームワークがバージョニングをいかに簡単にサポートしているかを確認してください。厳密に型指定され、シリアル化されたクラス インターフェイスは、インターフェイスに変更を加えるために何が必要かを明確に把握していれば、操作が簡単になる可能性があります。
リモーティングのビルトイン サポートはどうなりましたか?
http://msdn.microsoft.com/en-us/library/aa185916.aspx
必要に応じて、TCP/IP または IPC で動作します。WCF よりも高速で、コードに対してかなり透過的です。
ソケット、リモーティング、または WCF を使用できますが、それぞれに長所と短所があります。
ただし、パフォーマンスが重要でない場合は、WCF を使用してクラスをシリアル化および逆シリアル化できます。最大のパフォーマンスを得るには、ソケットをお勧めします
過去数年間、さまざまなバインドで WCF を広範囲に使用してきた経験から、WCF は手間をかける価値がないことがわかりました。
優れたパフォーマンスを維持しながら、チャネルのエラーを正しく処理するなど、WCF を正しく使用することは非常に複雑です (私たちは早い段階で wcf による高いパフォーマンスをあきらめました)。
認証されたクライアントのシナリオでは、http rest (wcf なし) に切り替え、json/protobuf ペイロードを実行します。
高速の非認証シナリオ (または少なくとも非 kerberos 認証シナリオ) では、現在 zeromq と protobuf を使用しています。