さまざまな目的で 20 以上のエンドポイントを作成する自己ホスト型の C# WCF サービスがあります。それぞれは、ポートやアドレスなど、サービスの app.config 内のいくつかの基本的な構成項目を使用して、コード自体で構成されます。このサービスは、テスト済みのクライアントではうまく機能しますが、広くテストされていません。
私は標準的な wcf 設定ファイルのアプローチに少し懐疑的でした。なぜなら、エンド ユーザーが物事を台無しにして、すべてをコードで行うのではないかと心配していたからです。
エンドユーザーがニーズに合わせてカスタマイズできるため、構成ファイルで構成を行うことをお勧めしますか、それともコード内のアプローチでほとんどのニーズに十分対応できますか?
WCF の主な利点の 1 つは、接続の詳細をコードから切り離して抽象化できることです。サービス パラメーターのいずれかを変更する必要がある場合は、web.config から変更する方が簡単で、再コンパイルする必要がありません。たとえば、「ポートとアドレス」を変更する必要がある場合があります。コード内からこれを実行している場合は、再構築する必要がありますが、これは非現実的かもしれません。さらに、本当に必要でない限り、エンドユーザーが通常どおり web.config をいじる理由がわかりません。
つまり、構成ファイルを使用しない正当な理由がない限り、WCF が提供する抽象化の利点を最大限に活用するために、構成ファイルを使用する必要があります。
あなたは自分自身にいくつかの質問をする必要があります
これらの質問のいずれかに対する答えが「はい」の場合は、設定を.configファイルに移動する必要があります。他の設定を理解しているクライアントが誤ってwcf設定を台無しにすることが心配な場合は、configSourceタグごとにweb.configまたはapp.configファイルに属性を追加し、構成の一部を別々に配置することで、いつでも設定を分離できます。偶発的な変更の可能性を減らすために、サブディレクトリ内のファイル。
単に、
このファイルを使用する.configと、コードのコンパイル後に構成を変更できます。これは、状況に応じて、良い場合も悪い場合もあります。