ビジネスロジックオブジェクトには、LINQ-to-SQLデータオブジェクトに関する知識が必要ですか？

Question

似たような質問をいくつか見てきましたが、自分に直接当てはまるものは見当たらなかったので、これが重複している場合はご容赦ください。

懸念を分離するために、.dbmlファイル内のLINQ to SQLデータオブジェクトへのロジックを使用して、ビジネスオブジェクトを何らかの方法でマップしようとしています（この点はまったく新しい）。しかし、どのように見えるかは、私のビジネスオブジェクトが対応するLINQ2SQLオブジェクトについて知る必要があるということです。 XMLマッピングファイルを使用してPOCOを使用しようとすることに関するこの記事。これは、テーブルからクラスへの1対1マッピングがないことを除いて、私が望むものと似ているようです余分なテーブルを作成するために必要な多対多の関係のためです。

ビジネスオブジェクトを使用するコードがデータベースに関する知識を必要としないように、ビジネスロジックにデータアクセスを非常にうまくカプセル化できますが、ビジネスレイヤーはデータアクセスと密接に結びついていますビジネスレイヤーオブジェクトを変更するか、異なるデータプロバイダー用に新しいオブジェクト（同じインターフェイスを実装する）を作成せずにDALを交換できないようなレイヤー。

これらのレイヤーを分離するにはどうすればよいですか？

Answer 1

LINQ to SQLに何とか結びついているかどうかはわかりませんが、達成しようとしているのはNHibernateのデフォルトです。 NHibernateを見て、LINQ to SQLと戦うよりも簡単に切り替えられるかどうかを確認することをお勧めします。

ツールとの戦いはほとんど常に悪い考えであることがわかりました。