9

さて、私は .NET Remoting について StackOverflow でいくつか質問しましたが、「.NET Remoting は非推奨です。代わりに WCF を使用してください」と口を挟まなければならない人が常に少なくとも 1 人はいます。これは非推奨であり、.NET Framework の新しいバージョンで将来サポートされる保証がないことを理解しています。しかし、WCF に移行したい他の正当な理由は何ですか? 私は .NET Remoting でほとんどマイナーな問題をいくつか見てきましたが、これは、「壊れていない場合は修正しないでください」と固く信じている権力者の考えを変えるには十分ではありません。現時点で、態度が変わる唯一の理由は、.NET Remoting が .NET Framework の将来のバージョンから削除された場合です。

WCF が .NET Remoting よりも正確に「優れている」理由、または Remoting が WCF よりも劣っている理由について、誰かが洞察を持っていますか? 各テクノロジーの長所と短所は何ですか? Remoting ではなく WCF でできることは他にありますか?

つまり、構成可能な TcpChannel タイムアウトをクライアント側で設定できるようにするためだけに、ソフトウェアを WCF に移行することを許可するように彼らを説得できれば素晴らしいことです (これは、どのような手順に関係なく、しばらくの間壊れていたようです)または私が試みるトラブルシューティング)、そしてこれが起こると、私たちのソフトウェアは絶対にたわごとのように見えます.

これについていくつかの光を当てるのを手伝ってくれてありがとう。

4

4 に答える 4

7

リモート処理をやめるべき理由はたくさんあります。いくつかは次のとおりです。

  • 輸送の柔軟性の欠如
  • バージョン管理の要件は大きな苦痛です
  • プラットフォームに依存する (クロスプラットフォームで使用する合理的な可能性はありません)
  • 成長するモバイル市場からの使用の機会がない
  • 将来の開発の欠如: 追加したい機能が何であれ、追加されることはありません

ただし、WCF が自動的に置き換えられるという点には同意しません。WCF 自体は非常に用途の広いツールですが、非常に複雑になる可能性があり、独自の制限があります。私はそれを自分で使用したことはありませんが、 Service Stackに対する多くの賞賛を見てきました。基本的に、ユーザーはそれを「WCFが正しく行われた」、つまり、WCFの優れた点であり、問​​題点はありません。ただし、他にも多くのオプションがあります。ただし、Service Stack のアイデアの良い点の 1 つは、反復処理が非常に迅速で、必要なものが不足している場合は変更できることです。

于 2012-09-28T07:36:00.620 に答える
5

.NET Remoting は、MSDN から引用された従来のテクノロジになりました。

このトピックは、既存のアプリケーションとの下位互換性のために保持されている従来のテクノロジに固有のものであり、新しい開発には推奨されません。分散アプリケーションは、Windows Communication Foundation (WCF) を使用して開発する必要があります。

また、2007 年に行われた WCF と .NET Remoting のパフォーマンス比較は次のとおりです: http://msdn.microsoft.com/en-us/library/bb310550.aspx

結果を要約すると、WCFは ASP.NET Web サービスより 25% ～ 50% 高速であり、 .NET リモート処理よりも約25%高速です。

したがって、スピードは .NET Remoting をやめる十分な理由だと思います。

于 2012-09-28T07:37:28.160 に答える
3

与えられた理由はおそらく運転上の考慮事項ですが、他にも重要な理由があります。

  • 輸送の独立性
  • IDE ツール
  • テストの容易さ
  • 保守性

WCF を使用すると、構成ファイルを編集するだけでトランスポートを変更できます。これは、機密性の高いシステム管理者がポートを開かず、企業のファイアウォールを通過するためにポート 80 で HTTP を使用する必要がある場合に非常に便利です。

Visual Studio の WCF ツールは驚異的です。最も難しいのは、必要な URL を見つけることです。その後は、ポイント アンド クリックするだけでコードを生成できます。コレクションのシリアル化には 1 つまたは 2 つの落とし穴がありますが、大まかに言えば、両端に配列を使用するように指示すれば、単純に機能します。宛先でコレクションが必要な場合は、受信した配列の周りにいつでもコレクションを構築できます。LINQ は配列で問題なく動作するため、これを他の変換に折りたたむことができます。

Stephan P がペイン ポイントで何を意味するのかわかりません。構成の編集は難しい場合がありますが、Microsoft は、オプションの完全なツリーを提供しながらも疎な構成ファイルを生成することで、当て推量をすべて排除する優れた GUI ツールを提供しています。

WCF サービスは、テスト ハーネスを接続できる公開されたインターフェイスを備えているため、簡単にテストできます。これは、特に WCF よりも一般的な SoA の利点ですが、それでもなお望ましいものです。

アプリケーションもサービスも「ルーティング」コード (メッセージの内容を処理する必要があるかを判断するため) で汚染されていないため、WCF を使用するとコードが大幅に簡素化されます。単純なメソッド呼び出しまたは実装のように見えます。私はほとんどの場合、MSMQ のラッパーとして WCF を使用します。トランスポートの選択の唯一の目に見える結果は、OneWay トランスポートであるため、これらのメソッド呼び出しはすべて void 関数でなければならないということです。しかし、ポイントが持続的なキューイングであった場合、それは驚くべきことではありません。

これはすべて保守性を物語っています。社内アプリケーションの場合でも、メンテナンスは主要なコストであり、顧客のサイトでソフトウェアをサポートしている場合、メンテナンス性の悪さが障害になる可能性があります。

次に、互換性のないプラットフォームとの相互運用性があります。この場合、HTTP/XML または HTTP/JSON を使用して、(たとえば) PHP で記述された Web アプリケーションにサービスを提供することを考えています。

他の方法はそれほど簡単ではありませんが、かなり簡単です。

于 2012-10-03T00:05:04.717 に答える
2

ロギングとセキュリティに関して、WCF にポイントを与えます。

ロギング WCF には、メンテナンス中に役立つトレースをログに記録するのに役立つ統合ロギング メカニズムがあります。他のテクノロジでは、開発者はこれを実現するために何らかの作業を行う必要がありますが、WCF では、構成ファイルを変更してトレースを有効にするだけで、WCF がトレースの提供を開始します。

セキュリティ WCF のセキュリティ メカニズムは、実装者の観点から見ると非常に単純ですぐに使用できますが、非常に堅牢で非常に安全です。最良の部分は、頻繁に使用され、推奨されるバインディングに対して、WCF がコアに信頼できる既定のセキュリティを提供することです。WSHTTPbinding のメッセージ セキュリティは、これらの行の例です。

.NET Framework のリモート処理は、既定では認証または暗号化を行いません。したがって、クライアントまたはサーバーとリモートで対話する前に、クライアントまたはサーバーの ID を確認するために必要なすべての手順を実行することをお勧めします。

さらに、WCF は、メッセージと rpc スタイルの両方のプログラミングを組み合わせた Microsoft プラットフォームでサービス指向アプリケーションを開発するためのフレームワークです。リモート処理にはありませんでした。リモーティングは基本的に rpc のみを対象としています。

于 2012-09-28T10:57:24.897 に答える