私は、ドメインロジックと永続性ロジックの懸念を分離するための最善の方法を模索しています。データアクセスにLinq-2-Sqlを使用しており、NerdDinnerチュートリアルに従っています。40ページを見ると、Linqで生成されたクラスのビジネスルールに部分クラスを使用していることがわかります。私にとって、それは間違っていると感じます（そうですか？）。アプリケーションのプレゼンテーション層に公開される独自のPOCOが必要です。ここでの1つのオプションは、個別のDTOクラスを使用することです。それは私には気分が良くなりますが、テストと保守のためにさらに多くのコードが追加されます。
部分的なクラスを追加してLinqクラスにビジネスルールを適用するという単純さは好きですが、データベースが変更された場合はプレゼンテーション層も更新する必要があるため、Linqクラスをプレゼンテーション層に公開するのは好きではありません。
データベースが変更された場合にプレゼンテーション層を更新する必要がないため、DTOアプローチはよりクリーンに感じられますが、処理するコードははるかに多くなります。
したがって、私の現在のアプローチは、2つのクラスライブラリです。1つはLinq-2-Sql DBML +部分クラスを持ち、もう1つは自動生成されたプロパティしか持たないクラスのセットを持ち、次に「リポジトリ」クラスからデータを取得することを管理します。 Linqアセンブリと変換IQueryable<T>.
もっと良い方法はありますか？より良い中間点はありますか？両方の長所を活かすことができますか？もしそうなら、どのようにそれらを異なるアセンブリに分離しますか？
アップデート
たぶん、私が本当にする必要があるのは、すべてのPersitence / Domainロジックを単一のアセンブリに統合し（NerdDinnerサンプルで使用されているのと同じアプローチ）、プレゼンテーション層に異なる「ビューオブジェクト」を作成することです。私のLinq-2-Sqlエンティティ？