アプリのテスターを使いやすくするために、依存性注入を実装しようとしています。私はかなり基本的な疑問を持っています。
データ層は、SqlConnection オブジェクトを使用して SQL サーバー データベースに接続します。SqlConnection オブジェクトは、データ アクセス レイヤーの依存関係です。依存性注入の法則に従って、依存オブジェクトを new() するのではなく、コンストラクター引数を介して受け入れる必要があります。DI の神々を混乱させたくないので、SqlConnection を受け取るコンストラクターを DAL に忠実に作成します。
ビジネス層は DAL を呼び出します。したがって、ビジネス層は SqlConnection を渡す必要があります。プレゼンテーション層はビジネス層を呼び出します。したがって、これも SqlConnection をビジネス層に渡す必要があります。
これは、クラスの分離とテスト容易性に優れています。しかし、たまたまリレーショナル データベースを使用するデータ レイヤーの特定の実装に、UI レイヤーとビジネス レイヤーを結合しただけではありませんか?
基になるデータ ストアが SQL であることをプレゼンテーション層とビジネス層が認識する必要があるのはなぜですか? アプリが SQL サーバー以外の複数のデータ ソース (XML ファイル、コンマ区切りファイルなど) をサポートする必要がある場合はどうすればよいでしょうか。さらに、データ レイヤーが依存する別のオブジェクト (たとえば、2 番目のデータベース) を追加するとどうなるでしょうか。ここで、この新しいオブジェクトを渡すように上位レイヤーを変更する必要があります。
このメリーゴーランドを回避し、痛みを伴わずに DI のすべてのメリットを享受するにはどうすればよいでしょうか?