1

WCFサービスを介していくつかのドメインロジックを公開しています。MVC WebアプリケーションでWCFプロキシ呼び出しなどを明示的に記述するのではなく、WCFサービス参照を独自のプロジェクト（MyProject.BizLogic.Endpoint）にラップしてから、このプロジェクトへの参照をWebアプリに追加しました。

これは、コントローラーコードをクリーンで読みやすい状態に保つのに最適です。Endpointは、RetrieveCustomerDetails（int customerId）などの抽象化されたメソッドを使用してICrmSystemインターフェイスを公開し、CustomerQuery DTOにラップされ、リモートのCustomerQueryHandlerサービスで起動されるエンドポイントクラス内に公開します。分離テストでは、ICrmSystemをモックし、モックされた実装に対してコントローラーメソッドをテストします。

つまり、WCFには多くの不可解で繊細な構成が必要であり、現時点では、Webアプリのweb.configファイルにsystem.serviceModelバインディングとクライアント構成全体を含める必要があります。

この構成を管理するためのよりクリーンな方法はありますか？できればエンドポイント抽象化モジュールの一部として、Web開発者がWCFが舞台裏で行われていることを知る必要さえないようにしますか？どういうわけか、エンドポイントの構成ファイルへの参照をWebアプリに入れることはできますか？または、宣言的ではなくプログラム的にWCF構成を管理しますか？

ありがとう、

ディラン

4

2 に答える 2

2

構成セクションを個別のファイルに分離できることがわかりました。これにより、構成を分離したままにすることと、実行時に編集できるようにすることのバランスが取れています。

私のWeb.configには次のものが含まれています。

<system.serviceModel>
    <bindings configSource="services/bindings.config" />
    <client configSource="services/myservice.endpoint.config" />
</system.serviceModel>

これは、実際のエンドポイントポート/プロトコルなどを意味します。独自のサブフォルダーで分離できます。このフォルダーは、VCSで外部（サブモジュール）として構成されているため、インフラストラクチャの一部を変更した場合（たとえば、サービスを別の物理サーバーに移動した場合）、構成を更新し、それらの変更をコミットし、プロジェクトを更新できます。これらの構成セクションに依存し、デプロイされた複数のアプリで構成ファイルを手動で更新する必要がなくなります。

唯一の注意点は、IISがメインのWeb.configの場合のようにこれらのファイルへの変更を検出しないことです。したがって、ファイルを変更した後は、web.configにタッチするか、Webアプリを再起動する必要があります。それ以外は、非常にうまく機能します。

于 2011-02-21T17:32:44.460 に答える
1

設定に保持します。サービスを他の場所に即座にポイントしたり、その場で新しい動作を追加したりすることができて、数え切れないほど何度も節約されました。コード化=コンパイル済み=変更が難しい

于 2011-02-18T20:24:13.747 に答える