0

再利用可能なコンポーネント/ライブラリを .net に設定する際に、何がベスト プラクティスと見なされるのか疑問に思っています。データベースと対話するためのいくつかのデータベース接続を含むライブラリを利用する Web サービスがあります。接続文字列の指定に関して、ライブラリをどのように設定すればよいか疑問に思っています。

dev/uat/prod 環境にデプロイするときに、再利用可能なコンポーネントが接続するデータベースを変更できる必要があります。また、誰がデータベース呼び出しを行っているかを追跡できるようにする必要があります。再利用可能なコンポーネントのユーザーが誰であるかを確認したい場合があるため、Web サービス A と B がそれぞれそれを使用している場合は、ws_A_usr を接続文字列、B についても同様です。

これを行う方法はいくつかありますが、いくつかのレガシーをリファクタリングしているため、3 つの実装すべてが使用されています。

構成から接続文字列を読み取る必要がありますか (MyLib.Properties.Settings.Default.abcConnectionString)

API のパラメーターとして接続文字列を受け入れる必要がありますか?

IDbConnection を API のパラメーターとして受け入れる必要がありますか?

これを行うための他のより適切な方法はありますか - 最良の方法は何ですか?

4

2 に答える 2

1

ライブラリはそのユーザー (この場合は Web サービス) から独立しているべきだと思います。その点で、構成ファイルに依存することはあまり良くありません。

Web サービスの web.config に接続文字列が必要ですが、ある時点でパラメータを介してライブラリに渡したいとします。これにより、Web 以外のプロジェクトで同じライブラリを使用できるようになります。また、接続文字列を取得するさまざまな方法を実装することもできます (おそらく Web サービス呼び出しから)。

HTH。ジョナサン

于 2009-04-21T09:32:22.283 に答える
0

私の考えでは、これは、接続がコンポーネントにどれだけ緊密にバインドされているかによって異なります。コンポーネントのみが使用するデータベースへの接続である場合、コンポーネントのユーザーにそれらの接続に関する情報を強制することは意味がありません。その場合、接続文字列を構成ファイル (app.config または web.config) に保持すると機能します。実際には、接続文字列をコンポーネントの内部に保持し、構成ファイルでデータベース サーバー名を公開することで十分な場合があります。

コンポーネントがコンポーネントのユーザーと同じデータベースを使用している場合は、接続をコンポーネントのプロパティとして渡すことを許可します。コンポーネントは、プロパティが設定されていない場合に組み込みの接続文字列をデフォルトにするか、プロパティが設定されていない場合に例外をスローするかを選択できます。

接続文字列全体をコンシューマーに公開してもかまわない場合は、文字列全体を app.config または web.config に配置できます。特に、.NET 2.0 アプリケーション設定機能 (Properties\settings.settings) を使用します。これにより、デフォルトがアセンブリにコンパイルされますが、コンポーネントが消費されると、これらのデフォルトが app.config ファイルに書き込まれます。そこから編集できます。

変更できる接続文字列の部分を制限する場合は、それらの部分をアセンブリにコンパイルします。変更を許可するパーツの個々のプロパティを公開します。特に、データベース サーバー名、アプリケーション名、ユーザー名、パスワードなどを公開します。これらのプロパティは、接続文字列の対応する部分を設定します。まだ知らない場合は、 SqlConnectionStringBuilder クラスを参照してください。

于 2009-04-21T11:26:15.300 に答える