これには何か考えがありますか?個人的には、設定ファイルのエンドポイントを管理するのは苦労します。もう片方をやり遂げることに賛否両論はありますか?エンドポイントとプログラムの構成/ web/app.config
答えて
私の設定ファイルを利用している点のみです。
構成ファイルのエンドポイントを管理するということは、エンドポイントが変更された場合にはアプリケーションを更新する必要がないということです。
アプリケーションの複数のインスタンスを異なるエンドポイントで実行することもできます。
オフハンドでは、設定ファイルのエンドポイントを変更したときに再コンパイルする必要はありません。これは、開発からUATへのアプリケーションの移動時に設定ファイルを更新するだけで済みます。
自宅で自分で使用するだけのものをコーディングすると、実際の違いはありません。しかし、ビジネス環境では、設定ファイルにenpointが定義されていれば、あらゆる種類の頭痛が救われます。
これは、必要な柔軟性の問題です。 私は設定ファイルの方が好きです。
app.configを使用している場合、変更に合わせてアプリケーションを再コンパイルする必要はありません。また、同じコードで複数の状況で再利用することもできます。最後に、エンドポイント(または変更対象のもの)をハードコーディングするのはコーディングが貧弱なことです。設定ファイルを恐れないで宣言的なプログラミングです。あなたは、「私はこのエンドポイントを使いたい」と言う。それはあなたのために仕事をします。
私はconfigファイルがかなり大きくなることができる以外、自分自身もconfigアプローチを好む傾向があります。
私はWCFの構成で気づいたことの一つは、あなたがあなたがは、独自のカスタムの拡張機能を追加することなく、XMLの設定で行うことができないコードから行うことができます多くのものがあるということです。言い換えれば、コード内でconfigを実行すると、より柔軟性が増します。もちろん、独自の拡張機能をコーディングして、それらの拡張機能を使用することもできます。
しかし、Visual Studioで自分の拡張機能を作成してXMLに含めると、VSが設定ファイルを気にしなくなり、タグ付けされるという「バグ」があると考えていることに注意してくださいエラーとして表示され、ウィザードを使用して新しいサービスを追加しようとすると、構成にエンドポイントを追加できません。
これは私自身の答えにフォローの一種である:xml構成のすべてを持っていることの数ヶ月後
、私はコード内のエンドポイントとバインディングを構築するために、すべてを変えています。私はコードでそれを持つための本当に良いケースを発見した。
WCFクライアントを含む展開可能/共有可能.dllを使用する場合。
たとえば、すべてのWCFインターフェイスといくつかのリモートサーバーとの通信契約を含むCommonClients.dllを持っている場合は、「こちらは100行のxmlもあります。すべてのクライアントのためにapp.configに落として "この場合、コードで構築されたすべてがよりうまく機能します。
.NET 3.5の「機能」もあります.WCF拡張機能を使用する場合は、完全修飾アセンブリ名を指定する必要があります。つまり、拡張機能を含むアセンブリでバージョン番号が変更された場合は、設定ファイルでアセンブリ名を変更する必要があります。 .NET 4では、短いアセンブリ名を使用し、完全な名前は必要ないと思われます。
私は一般にプログラムの設定を行います。私は自分のアプリケーションの内部構造をユーザーに公開したくないからです。私が設定可能な唯一のものはサービスアドレスですが、これも私はsystem.ServiceModelではなくuserSettingsセクションにあります。
私は構成ファイルの方法を推奨し、推奨します。アプリケーションを再コンパイルせずにサーバーを変更できるため、柔軟性が大幅に低下します。 セキュリティが必要な場合は、設定ファイルを暗号化できます。
プレーンな設定ファイルの最大の心配は、アプリケーションがクラッシュするエンドユーザによって誤って(意図的に)変更される可能性があります。これを克服するために、コードでいくつかのテストを行って、設定ファイルで設定がOKであるかどうかをチェックし、そうでない場合はデフォルトでプログラムで初期化します。私はあなたが別の答えでそれをする方法を提示しましたthis質問。
.NET StockTrader appを参照してください。リポジトリは設定データを保存するためにリポジトリを使用し、設定を管理する別のアプリを持っています。セットアップと構造はかなり進歩しています。私のようなWCF設定の基本を持っている人なら誰でも頭を引っ掻いているようですが、一見価値があると思います。
- 1. サービスファブリックのエンドポイント構成
- 2. Restfull APIの構成エンドポイント
- 3. wcfでエンドポイント構成を書き込む方法プログラムでC#
- 4. WCFサービスの複数のエンドポイント構成
- 5. プログラムで構築されたエンドポイントでWCFビヘイビア拡張を宣言的に構成します。
- 6. Apache Camel - エンドポイントとエンドポイントを動的に構築する
- 7. REST API upsertエンドポイントとエンドポイントの作成と更新
- 8. 残りのエンドポイント構造
- 9. スプリング構成のcamelContextを使用したCamelエンドポイントの模擬
- 10. Scrapy:セカンダリウェブサイトとのやりとりのプログラム構成
- 11. wsdl:portのWCFエンドポイントを構成する方法
- 12. プログラムによってエンドポイントのID構成を変更する方法はありますか。
- 13. 構成とプロパティの構成
- 14. OpenGLとOOPプログラムの構造
- 15. プログラムでSSISパッケージ構成をロードする
- 16. Log4j2構成ファイルをプログラムでロードする
- 17. エンドポイントReaderQuotasをプログラムで変更する
- 18. Liferay 6で構造とテンプレートをプログラムで作成する方法
- 19. t.c.telnetでエンドポイントを構築する方法
- 20. Java omniorbを使用するサーバーのエンドポイント構成を指定する方法
- 21. C#プログラムの構造
- 22. Rubyプログラムの構造
- 23. Rubyプログラムの構造
- 24. スカラパーサーコンビネータと再構成構造
- 25. 構文エラー++プログラム
- 26. クラウドフォレンジリのローカルマシンのAPIエンドポイントを作成
- 27. 明示的エンドポイントの子プロセスの生成
- 28. Webアプリケーションテストフレームワークの構成と構造
- 29. マイクロサービスのプロジェクト構造と構成
- 30. サーブレット3.0のエラーページのプログラムによる構成