エンティティへのlinqに関する記事を読むたびに、生成されたエンティティクラスにビジネスロジックを埋め込む必要があります。エンティティとビジネスロジックへのLinq
これは、ビジネスオブジェクト（コントローラ、サービス層など）の「ユーザー」が、linqを使用するために必要なdatacontext-objectについて知っていなければならないことを意味します。
これは、DALロジックとビジネスロジックが混在することを意味します。
多くのMicrosoftの例では、ある種のDTOアプローチを使用しています。私はDTOパターンの大ファンではありません。
ビジネスオブジェクトにlinqエンティティをカプセル化させ、プロパティを使用してそのオブジェクトへのアクセスを許可する必要がありますか、またはDTOパターンに固執する必要がありますか？
あなたの提案は何ですか？彼らは変更する可能性があるとして、私は生成されたファイルを編集しないでしょう
おかげ
エンティティモデルは部分クラスを生成します。私のプロジェクトでは、クラスライブラリ内でエンティティモデルを使用しており、いくつかの.csファイルを追加してデフォルトのエンティティクラスに機能を追加しています。 （ほとんどの機能は、データベーステーブルへのエラーとメッセージのロギングに関連し、XMLへのすべてのデータのインポート/エクスポート方法です。）真のビジネスロジックは、このエンティティクラスライブラリを参照する第2クラスライブラリにあります。
次に、ビジネスロジックを含む2番目のプロジェクトを追加します。ここでも、「新規プロジェクト|クラスライブラリ」を使用して作成し、参照にEntity.Model.dllを追加します。次に、データベース固有のクラスをより論理的なクラスに変換するクラスの作成を開始します。一般的に、私はいくつかのフィールドを保護または隠し、いくつかの計算フィールドを追加する以外は、多くの変更を加える必要はありません。ビジネスロジックは、私がクライアントアプリケーションからアクセスしたい機能だけを公開し、単一の方法ではありません。したがって、クライアントに企業の削除を許可しないと、エンティティモデルの「削除」機能がでなく、がビジネスレイヤに公開されます。会社が住所を変更したときに通知を送信したいので、会社のアドレス欄が変更されたときにトリガーされるイベントを追加します。 （これはメッセージログなどを書く）私はこのbusiness.logicを呼び出し、Business.Logic.dllにコンパイルします。
最後に、クライアントアプリケーションを作成し、Business.Logic.dllへの参照を追加します。 （ただしエンティティモデルではありません）。私は今、アプリケーションを作成し、ビジネスレイヤーを介してデータベースにアクセスすることができます。ビジネスレイヤーは、検証を行い、いくつかのイベントをトリガーし、エンティティーモデルを介してデータベースを変更するだけでなく、何でも実行します。また、エンティティモデルはデータベースの関係を単純に保ち、データベース内のすべての外部リンクを介してデータを「ウォークスルー」できるようにします。
。
あなたができることは、それらにいくつかのクエリオブジェクトをラップし、それを渡すことです。 DALは本当にまた
を生きるべきところ、あなたはのviewmodels/DTOSのファンであるべき程度
あなたは、（Microsoftの例のように）クエリオブジェクトを使用する多数の「ステートレス」マネージャクラスを作成することをお勧めしますか？ 私のビジネスクラスにはクエリオブジェクトのインスタンスが含まれ、これを下位のレイヤーに公開する必要がありますか？このようにして、ビジネスオブジェクトにsaveメソッド、loadメソッドなどを持たせることができます。 –
永続性はビジネスロジックとは関係ありません。 "linq to entites"と言うと、 "linq to sql"ではなく "linq to objects"を意味しますか？もしそうなら、私は本当に自動生成ツールを使用しないでしょう。自分でxmlを編集するか、流暢なlinq2sqlを使用してください。エンティティはほぼPOCOになり、サービスクラスとともにビジネスロジックを持つことができます。 linq2sqlはmsで落としてしまったので心配してください。 –
彼は明らかにlinq2entitiesについてではなく、linq2sqlについて話しています。さらに、linq2sqlは「吸う」ために削除されていません。マイクロソフトはEntity Frameworkに焦点を当て、2つの発散的な取り組みを1つにまとめました。 – Chrisb
ビジネスクラスのエンティティクラスへの呼び出しをラップすることをお勧めします。 （BCと略して呼んでいます。）それぞれのBCにはいくつかのコンストラクタがあり、そのうちの1つ以上がコンテキストを渡すことができます。これにより、1つのBCが別のBCを呼び出し、関連するデータを同じコンテキストでロードすることができます。これにより、共有コンテキストをより簡単に必要とするBCのコレクションを処理することもできます。
コンテキストを取らないコンストラクタでは、コンストラクタ自体に新しいコンテキストを作成します。他のBCがアクセスできる読み取り専用のプロパティでコンテキストを利用可能にします。
MVVMパターンを使用して書き込みます。このアプローチの良い点は、今まで私のモデルを構成するBCだけでデータコンテキストを参照することなく、自分のビューモデルを書くことができたことです。したがって、私のデータアクセスを変更する必要がある場合（エンティティフレームワークを置き換える、またはベータ版からバージョン4にアップグレードする）、私のビューとビューモデルは、BCで必要とされる変更から分離されます。
これが最良のアプローチであるかどうかはわかりませんが、これまでのところ私は結果が好きでした。 BCを正しく設計するには調整が必要ですが、柔軟性があり、拡張性があり、維持可能な一連のクラスが完成します。
お返事ありがとうございます。BCのプロパティとしてデータを公開するか、何らかの方法（GetCurrentData（）など）を使用してクエリの結果を公開するだけですか？ –
私はアクセスが必要なエンティティオブジェクトの特定のプロパティ/フィールドを公開します。 BCの外でエンティティオブジェクトのフィールドまたはプロパティを公開する必要がない場合は、公開プロパティまたは保護されたプロパティまたはメソッドを作成することはありません。私はしばしば、内部ロジックをよりよくカプセル化するためのプライベートプロパティ/メソッドを作成します。 –
回答ありがとうございます。 しかし、2番目のクラスライブラリはエンティティモデルをどのように「使用」していますか（前の回答に対する私のコメントを見てください）。 –
エンティティクラスライブラリはパブリッククラスです。 2番目のクラスの参照に追加され、2番目のクラスのエンティティクラスの名前空間が使用されます。どちらのクラスライブラリも.DLLアセンブリにコンパイルされます。私は上記の私の答えに長い説明を追加します。 –