構成ベースの共有ライブラリ（DLL）

Question

私は小さなASP.Net/C#アプリケーションがたくさんある会社で働いています。私は、一般的な機能（Active Directory参照、FTPなど）用の共有ライブラリを作成することにより、できるだけ多くの機能を集中化するよう努めてきました。

私は、SMTPのやり取りを実行する電子メールdllを作成しようとしています。私はこのconfigベースの動的なので、私はすべてのweb.configにSMTPサーバー名、ポートなどを配置する必要はありませんようにしたいと思います。

設定ベースの共有ライブラリを作成するが、各アプリケーションのweb.configに依存しないことがベストプラクティスですか？私はそれがmachine.configに結び付けられないようにしたいので、移植性があります。

私は、各アプリは、パラメータを渡すことなく、メソッドを呼び出すことができるようにしたい：

EmailLib.SendEmail("a@b.com", "This is the subject",....); 

感謝。

Answer 1

設定はどこかに保存する必要があります。 。 。データベースがオプションになる可能性があります。アプリケーション固有の構成表のようなもの。リフレクションを使用して、呼び出し元のアプリケーションの名前を判別し、それを使用してデータベース表の行をルックアップすることができます。しかし、データベース接続をどのように構成しますか？チキン？卵？最初？

GWは良いアイデアを持っていますが、必要なデータ（設定ファイル、データベース接続）を「ハードコード」している場合があります。ウェブサービスであっても、別のドメインから電子メールを送信したり、どのドメインから送信するかをWebサービスに伝える必要があります。

Answer 2

WebサービスまたはWCFサービスに電子メール機能を組み込むことができます。これにより、1つの場所に設定が保存されます。

Answer 3

私は、基本的には名前テーブルを読み書きするdbテーブルへの単なるライブラリである「設定」ライブラリを作成しました。多くのデータ型を保持するのに十分な柔軟性を持ち、再利用可能です。このようなライブラリを他の各ライブラリに簡単に実装できます。

AgileSetting.SetSetting("EmailSubject", "All your base are belong to us"); 
string emailSubject = AgileSetting.GetSetting("EmailSubject"); 

また別のレベルに持ち帰り、整理に役立ついくつかの種類の設定を作成することもできます。

Answer 4

私は長期的には、とにかくそのようなハードコードされたものを使いたくないと主張します。あなたのすべてのアプリはおそらくサポートのために別の電子メールアドレスを持っているでしょうし、おそらく別の主題を使用したいと思っています。（foo-corp appで一般的なエラーではなく、

しかし一般的な問題としては、「.properties」ファイルを持つことができます。一般的なNAntビルドは、ある種の方法で適切に処理されます。

Answer 5

私は、各アプリケーションのweb.config（またはアプリケーション設定）ファイルに設定情報を保存することをお勧めします。

本当にそれをしたくない場合は、あなた自身が「あなた自身のロール」領域にいる可能性が高いです。特に、通常の.NET設定ファイルのようには見えないものを書くつもりです。将来のメンテナーがあなたのしていることについて混乱することはありません。

DLLの設定ファイルは常に厄介です。異なるアプリケーションにDLLの設定ファイルの設定が異なるようにするとすぐに、重要なデプロイメント、メンテナンス、ソース管理、ユニットテストの問題が発生します（これは設定が最初の設定ファイルにある主な理由の1つです、 右？）。

一般に、設定の設定はコンポーネントではなくアプリケーションに属します。

Answer 6

私は、IOCコンテナに格納された外部ファイル（例えば、xml、dsl）から設定され、次にそれを使用しているサービスに注入される構成クラスを作成することが賢明です。このプロセスはここでよく説明されていますconfiguration in conjunction with an IOC container

この利点は、サーバーごとに複数の構成があり、単体テストのクラスに構成を注入することができることです。私は文字列や何かにintを変換することについて心配する必要がありますので、すべてが強く型付けされています。