3レイヤーのASP.Netアプリケーション（プレゼンテーションレイヤー、ビジネスレイヤー、データアクセスレイヤー）を作成する場合、Connectionオブジェクトを作成する最適な場所はどこですか？ASP.Netのデータアクセスレイヤー：どこで接続を作成しますか？
これまで私のプレゼンテーションレイヤーでヘルパークラスを使用して、各ページのweb.configのConnectionStringからIDbCommandを作成し、それをDALクラス/メソッドに渡しました。
明らかに、データアクセスの一部であるため、この部分をDALに含めるべきではないと確信しています。 DALは別にコンパイルされたプロジェクトに入っているので、web.configにアクセスできず、接続文字列にアクセスできません（右？）。
ここでベストプラクティスは何ですか？
短い答えは：
データベースへの依存関係を表すConnectionオブジェクト、中に作成された（とのみに知られている）データアクセス層をする必要があります。
長い答え：
あなたは「3ティア」と言うとき、あなたが本当に「ティア」を意味するか、またはあなたは「層」を意味するのですか？前者は、各階層の間にサービス層などのハード境界を示唆しています。後者は、単一のアプリケーションコンテキスト内の論理的な分離にすぎません。また、DALがどのように「個別にコンパイルされたプロジェクト」であるかを定義します。コードを実行しているアプリケーションコンテキストの設定ファイルにアクセスできます。それが独自の層であれば、何らかのサービスや設定を持つものがあります。単なるレイヤーの場合、アプリケーションのメイン設定にアクセスできます。
理想的には、データベースに関連付けられている、および/またはデータベースに依存しているものは、DALにのみ存在する必要があります。残りのアプリケーションドメインは、データベースについて心配するべきではありません。
私はそれがサービス層にあるべきだと思います、それはユースケースを満たすものです。作業単位を知っているオブジェクトは、接続を作成し、トランザクションレベルを設定し、ユースケースを満たし、必要なものをクリーンアップするものでなければなりません。
プレゼンテーションテクノロジを変更した場合は、接続作成をやり直す必要があるため、プレゼンテーションレイヤには含めないでください。
+1私はそれをより良く言ったことはありませんでした。 –
とにかくひどく設計されているアプリケーション構造の詳細には行きたくありません。私の主な質問は：私はDALからConnectionStringにアクセスする必要がありますか？ DALを使用するウェブサイトへの依存を作成しないのですか？ – magnattic
@atticae：あまりにも多くの詳細がなければ、はいといいえ。設定ファイルの形式での依存関係は、単に「このライブラリを使用するには、これらの設定オプションを設定する必要があります。これは、複数の環境やアプリケーションコンテキストで使用できるライブラリにとっては非常に標準的であり、期待されています。 DALはおそらくハードコードされたデフォルト値を持つことができ、設定値がない場合に使用されます。しかし、インフラ/環境の依存関係を扱うライブラリが、それらの依存関係に関して構成されることを期待するのは無理ではありません。 – David