1

現在のサービス層のデータ アクセス層にリポジトリ パターンを実装しました。

同じクラスの「歴史的メモ」が複数のオブジェクトにマッピングされているオブジェクト モデルがあります (現在は 6 つですが、すぐにそれ以上になる予定です)。

linq to sql を使用するためのベスト プラクティスの一部は、db 内のテーブルごとに 1 つの dbml ファイルを作成するのではなく、それを分解することです。この方法では、コンテキストが作成されたときにパフォーマンスに大きな影響が及ぶことはありません。

残念ながら、オブジェクトを分離する論理的な場所により、5 つの異なる DBML ファイルに歴史的なメモが残されています。linq ジェネレーターがクラスを作成すると、別の名前空間に別のクラスが生成されます。

ドメイン モデルに履歴メモ オブジェクトがありますが、履歴メモを使用するたびにドメイン オブジェクト モデルをデータ モデルに再マップする必要はありません。

やりたくないことの 1 つは、データの「読み取り」を複数のクエリに分割することです。

履歴メモを複数のデータ モデルにマッピングし、マッピングを 1 回だけ書き込む方法はありますか?

ありがとう

ピート

解決

助けてくれてありがとう。すべてのデータ テーブルに対して 1 つのデータ コンテキストに戻ろうと思います。

複数のモデルのセットアップに伴う回避策は、コードの余分な複雑さと潜在的な脆弱性に見合うものではありません。歴史的なメモをマッピングするために左手と右手のコードを同じように書かなければならないのは、あまりにも多くの作業とコードの同期を保つための場所が多すぎます。

入力してくれてありがとう

4

2 に答える 2

1

linq to sqlを使用するためのベストプラクティスの一部は、db内のテーブルごとに1つのdbmlファイルを用意するのではなく、それを分解することです。これにより、コンテキストの作成時にパフォーマンスに大きな影響を与えることはありません。

どこで聞いたの?同意しません。DataContextは、テーブルの数に関係なく、一般的にかなり軽量なオブジェクトです。

複数のデータコンテキストに関連する問題の分析については、こちらをご覧ください。

LINQ to SQL:単一のデータコンテキストまたは複数のデータコンテキスト?
http://craftycodeblog.com/2010/07/19/linq-to-sql-single-data-context-or-multiple/

私の意見では、データベースごとに1つのデータコンテキストが必要です。 これにより、マッピングの問題も解決されます。

LINQ to SQL:プロジェクトごとに複数/単一の.dbml?も参照してください。

于 2010-08-05T04:05:14.867 に答える
0

1 つのオプションは、履歴メモを独自のデータ コンテキストに配置し、このオブジェクトとモデルの残りの部分との関係を「id」として保持することです (データベース内の外部キーのみ)。それがとにかく私がそれをする方法です。

于 2010-08-05T16:40:29.983 に答える