人々がよりスケーラブルな方法で dbml ファイルを管理する方法を知りたいですか?
DataClasses1.dbml が 1 つだけあり、すべてのテーブルをそこにドラッグしますか?
アカウント、HR など、個別の論理グループ用に個別のファイルがありますか? もしそうなら、あるテーブルが別の dbml ファイル内のテーブルへのリンクを持っている場合、外部キーの関係を視覚的に確認するにはどうすればよいでしょうか?
ありがとう。
人々がよりスケーラブルな方法で dbml ファイルを管理する方法を知りたいですか?
DataClasses1.dbml が 1 つだけあり、すべてのテーブルをそこにドラッグしますか?
アカウント、HR など、個別の論理グループ用に個別のファイルがありますか? もしそうなら、あるテーブルが別の dbml ファイル内のテーブルへのリンクを持っている場合、外部キーの関係を視覚的に確認するにはどうすればよいでしょうか?
ありがとう。
DBML
すべてのテーブルに1 つのファイルを使用することをお勧めします。これにより、すべての関係Foreign Key
を一緒に確認できます。
Entity Framework の使用 (linq-to-sql と同じ) データベースの個別の部分に個別のコンテキスト クラスを使用するのが好きです。
しかし、「異なる」とは何ですか?
ほとんどの場合、アプリケーションのコア ビジネスに関連するものはすべて相互に関連しすぎているため、別のコンテキストでは意味がありません。しかし、ほとんどすべてのアプリケーションには、承認、翻訳、監査などの横方向のタスクがあります。これらは、個別のコンテキストの適切な候補です。
ただし、ビジネス ロジックへの接続は引き続き存在します。おそらくご存じのとおり、結合が SQL に変換されるような方法で、別のコンテキストからクラスを結合することはできません。メモリ内のみ。したがって、いくつかのエンティティを複数のコンテキストで複製すると便利です。したがって、たとえば、ビジネス コンテキストと承認コンテキストの両方にUser
エンティティが含まれます。1 つのコンテキストがエンティティのメンテナンスを担当し、他のコンテキストはそれを読み取り専用で使用する必要があります。
編集
エンティティの複製とは、2 つ (またはそれ以上) のコンテキストが、データベース内の同じテーブルにマップされるエンティティを持つことができることを意味します。のようにUser
。必要に応じて、ビジネス コンテキストはユーザーを作成および更新するためのものであり、承認コンテキストは (たとえば) 特定のユーザーにロールを追加するためのものであり、ユーザー自体を変更することはありません。