私たちはマルチサービスアプリケーションを持っています。 WCFエンドポイントによって公開される別のコンポーネントにDBアクセスを伴うメソッドを移動しました。
2つのオプションがあります。
1.メソッドへのWCF呼び出し。
2. DIエンジンで解決されたメソッドを直接呼び出します。
システムのパフォーマンスは重大な問題であるため、クライアントアプリケーションを再コンパイルせずに構成ファイルを使用して、オプション1とオプション2を切り替える必要があります。
このアイデアやアーキテクチャに関するヒントや提案はありますか？このアイデアやアーキテクチャに関するヒントや提案はありますか？
インターフェイスでWCFサービスを解決するようにUnityに指示できます。したがって、サービスやWCFのローカル実装を解決することは重要ではありません。あなたはいつもあなたのクラスにIMyServiceを注入します。それは単にあなたの設定の変更です。
あなたはapp.configをまたはWCFの発見を使用するように拡張を設定するか、明示的にコード内でバインディングとEndpointAddressを指定することができます。
詳細については、TecX projectを参照してください。ソースコードはTecX.ServiceModel.AutoMagicにあります。使用法を示すいくつかのテストがTecX.ServiceModel.Test
で見つけることができます更新
（例えばIMyService）あなたのサービスのためのインタフェースを定義し、必要な属性とそれを飾ります（DataContract,OperationContract）。そのインタフェースを実装します（クラスMyServiceなど）。 MyServiceメソッドを呼び出します。今直接たMyServiceにマップIMyServiceのいずれかにUnityに伝えたり、WCFのChannelFactory によって生成されたプロキシにIMyServiceをマッピングすることを可能にするコンテナの拡張機能を追加します。サービスを展開すると、完了です。 Unityは、IMyServiceの実装を必要とするクラスのコンストラクタに注入します。
システムパフォーマンスが重要な問題であり、このような設計を推進する他の要件がない場合は、余分なWCFレイヤーを避けるべきだと思います。いくつかのパフォーマンステストを実行して、そのオーバーヘッドが受け入れられるかどうかを確認することもできます。最終的には、どのオプションがあなたに適しているかを決めることができるので、切り替えの必要性を取り除きます。
WCF機能の一部が必要な場合（例：信頼性、耐久性、エラー・マスキング、フォールト・アイソレーション、バッファリングとスロットリング、データ・バージョニング耐性、リモート性、相互運用性、キューイング、ディスカバリなどの機能を備えています。 WCFはあなたができる最良の選択です。市場で他の枠組みはそのパフォーマンスと競合することはできません。 –
はい、ただし必要がある場合のみ... – henginy
"オプション1とオプション2の間で、クライアントアプリケーションを再コンパイルせずに設定ファイルを使用して切り替えたい"というトレードオフを知っている。主なポイントはどうやってこのarchirtectureを実装できるのか？ – shahzad
すばらしい説明....セバスチャン・ウェーバー.....ありがとう。 – shahzad
@shahzadもし私の答えが役に立ったら、そのようにマークすることができれば素晴らしいだろう。 –