Linq to SQL と、分離されたリポジトリを備えた DDD スタイルのドメイン レイヤーを使用して、L2S の問題をドメイン レイヤーに流出させずに仕様パターンを実装する方法について、まだ理解できる良いアイデアはありますか? :)
一連のトランザクション データの選択を取り巻く複雑なビジネス ロジックがあり、それらのルール/仕様をドメインが所有することを望んでいます。また、ドメインの永続性を無視し続けることにも成功しています。
仕様を実装するために、ドメインは (私が知る限り) 照会されるタイプ (L2S タイプ) を確認する必要があるため、これは問題を引き起こします。
何か案は？
また、説明したくない理由により、nHibernate は問題外です.. :)
一般的な仕様を、Expression適切な L2S 構文に変換されるツリーにマッピングすることを検討しましたか? それがあなたがここでぶつかっている主な問題のようです。仕様パターンは問題ではありませんが、L2S へのマッピングが問題です。
私は最近同じ問題を抱えていました。パターンは異なりますが、それでも LINQ to SQL (L2S) です。漏れを避けるために、2つの異なる方法を試しました。
まず、DTO とマッピング レイヤーを使用してみました。そのため、テーブルへの 1 対 1 のマッピングを持つ非常に単純なオブジェクトを作成しました。それらはすべて L2S 属性で装飾されていました。次に、DTO をビジネス オブジェクトにマップするためのマッピング レイヤーを作成しました。これらはすべて、Doman Driven Design のリポジトリ パターンによって隠されていました。そのため、ビジネス オブジェクトの消費者は、L2S が内部にあることを知りませんでした。
次に、主にバラエティです。L2S の XML マッピング機能を使用してみたため、オブジェクト自体に属性は必要ありませんでした。コレクションについては、L2S コレクションの代わりに IEnumerable を公開しました。ビジネス クラスの内部を見れば、L2S (EntitySet または Ref) の使用をまだ検出できます。しかし、クラスの消費者は知りませんでした。そのため、多少の漏れはありますが、抜本的なものはありません。
結局、最初のパターンに固執しました。2 つ目は機能し、ビジネス レイヤーのインターフェイスを変更せずに L2S を置き換えることができましたが、XML マッピングには満足できませんでした。最初のパターンでは、データベースとビジネス オブジェクトがより明確に分離されていました。より多くのコードが必要でした。最初の方法は、テーブルとは異なる方法でビジネス オブジェクトを進化させることができたので、私たちにとってはうまく機能しました。プロジェクトの初期には、オブジェクトがテーブルとほぼ 1 対 1 であったため、xml マッピングが機能していました。
そのため、最終的に L2S とドメインの間にレイヤーを配置します。出来た。より多くのコードが必要でしたが、本当に単純なものでした。そして、それはすべて非常にテスト可能でした。
ドメイン レイヤーから Linq2Sql を参照したくない場合は、実際のエンティティ自体を操作するのではなく、エンティティを表すインターフェイスに対して操作する必要があります。次に、インターフェイスとエンティティの間にマッピング レイヤーが必要です。
私はこの方法で作業してきましたが、それが深刻な障害であることがわかりました。新しいプロジェクトでは NHibernate に切り替え、古いプロジェクトでは、Linq2Sql エンティティを直接参照するドメインについて心配するのをやめただけです。私の意見では、その制限を克服することは、単に時間がかかりすぎます。
Linq-To-Sql クラスは部分的なものにすることができます。これは、共通のインターフェースを実装するパーシャルを実装することで、それらを拡張できることを意味します。そのインターフェースは、あなたが説明している「出血」の問題なしにレイヤー間で共有できます。残りは、簡単にカプセル化できるはずの「IsStatisfiedBy」の詳細です。