1

私はいくつかのことを理解しようとして頭を叩いてきました。そこで、アドバイスや調査資料を (リンク経由で) 探しています。シナリオは次のとおりです。

他のいくつかのアプリケーション (AppA、AppB、AppC など) が必要とするリソースを含むライブラリ (CommonLib など) があります。これが現在機能している方法は AppA インスタンスで、特定のポートが使用可能かどうかを確認します。そうでない場合は、CommonLib をキックし ("Hey, wake up")、サービスを開始します。その後、AppA は満足して出発します。

現在、Remoting.Channels について多くの調査を行った結果、「レガシー」と見なされるテクノロジに基づいて構築されたアプリケーションを開始しようとしているという結論に達しました。うーん...私はそれが好きではありません。正直なところ、WCF は必要以上にオーバーヘッドが大きく、Mono では完全に実装されていません。マルチプラットフォームの互換性 (Windows、Mono、Linux) をターゲットにしているため、すべてのオプションを調査しています。

そもそも、リモーティングのアイデアが始まったのは、CommonLib を単一のインスタンスとして保証したかったからです (私が理解しているように、シングルトンは特定の AppDomain 内のシングルトンであることがほとんど保証されているだけです。間違っています）。とにかく、私はリモート処理の威力を実感し、実験的な実装を開始することにしました。MarshalByRefObject の最初の使用に成功しました。しかし、私は、このレガシー テクノロジーの継続的な実装について懸念しています。

それで、これらすべてで... CommonLib を（ホストアプリケーションとして）実装し、リモート処理なしで、ストリーム、標準の TCP ソケット、またはその他の方法で MarshalByRefObject を実装する方法を検討しています。私が考えているのは、AppA をインスタンス化して CommonLib を実行する代わりに、CommonLib をベース アプリとして実装することです。次に、CommonLib 内でインスタンス化するアプリ (実際には単に「ホストされている」.dll) を選択します。次に、CommonLib は、その .dll を、ホストされているアプリが使用するカスタム コントロールと共に CommonLib フレームワークに読み込みます。この考えに加えて、CommonLib が本物のシングルトンでなければならないという要件 (今のところ) は差し控えたいと思います。

これがシナリオの詳細です。繰り返しますが、私の質問は実際には 2 つの部分です: (a) どのテクノロジを調査する必要があるか、および (b) リモート処理テクノロジのレガシー ステータスに関心を持つ必要がありますか?

その他のアドバイス、コメント、または質問は大歓迎です。

更新 1:このスニペットから始めます。これにより、インストールされているアプリ (またはプラグイン) のリストを含むファイル (またはスクリプト) を読み込むことができます。このファイルを Xml またはバイナリ形式で作成できます。新しいアプリをインストールすると、ファイルとパスを追加できます。うーん...必ずしも MarshalByRefObject を使用する必要はありません。

4

2 に答える 2

2

WCFはMonoで完全ではないかもしれませんが、Mono2.6はSilverlight/ Moonlightに必要なすべてを提供するため、WCFベースの実装は完全に実行可能である必要があります。エキゾチックなもの（さまざまなトランスポート、インスペクターなど）を試さない限り、Windows/モノラルなどの間で信頼できるRPCスタックを提供するだけで十分です。

WCFとリモーティングの主な違いは使用法にあります。リモーティングは別の端にあるふりをするオブジェクトに基づいていますが、WCFはサービスに基づいています。重要なのは、（プロパティなどにアクセスするのではなく）個別のメソッドに基づいて対話を行う必要があるということです。これには、境界を越えているときに明示的にするのに役立つという利点もあります。

もう1つのオプションは、非常に基本的なソケットサーバーを作成することです。非常に軽量で、protobuf-netのようなものを使用して、ポータブル（クロスプラットフォーム）シリアライザーの実装を提供できます（BinaryFormatter2つの間で実際に信頼するべきではありません-それは...薄っぺらです）。

要するに-私はまったく構築しませんでしMarshalByRefObject た; 次のようなサービスレイヤーを作成します。

interface IMyService {
    void Method1();
    int Method2(string s);
}

発信者からこれらの詳細を抽象化します。最終的にWCFを使用する場合は、それだけで十分です。また、既存のリモーティングサポートについては、ストーリー全体を（非公開で）カプセル化IMyServiceする実装を作成します。ソケットサーバーを作成した場合も同様です。MarshalByRefObject

于 2010-01-24T08:33:26.517 に答える
1

.NET Remoting が WCF によって廃止されたかどうかはわかりません。ユースケースは多少異なると思います。WCF には (意図的に) "参照によるマーシャリング" の概念がありません。これは、遅延などによるおしゃべりなプロトコルを回避する必要がある可能性のある、分散された (比較的) 疎結合のアプリ向けに設計されているためです。コンポーネントが自然に密結合されている場合、遅延は低くなりますが、パフォーマンスを高くする必要があり、豊富な .NET 型を維持することが重要であるなどの場合は、リモート処理が適している可能性があります。とにかく、「レガシー」であることを心配する必要はありません。少なくとも Windows/.NET では、「レガシー」テクノロジは、十分な量の使用が得られれば、かなりの時間使用する方法があります。リモート処理は、.NET の最新 (4.0) バージョンにも存在します。

これは、リモーティングが必ずしもあなたの状況に最適であるという主張を意味するものではありません...

于 2010-01-24T05:27:18.797 に答える