この質問は、LINQ to SQL .dbml のベスト プラクティスに関するこの質問である程度対処されていますが、質問に追加する方法がわかりません。
当社のアプリケーションの 1 つは LINQ to SQL を使用しており、現在、データベース全体に対して 1 つの .dbml ファイルがあり、管理が難しくなっています。よりモジュール/機能に固有の個別のファイルに少しリファクタリングすることを検討していますが、1 つの問題は、アソシエーションが . dbml ファイル (私が知る限り) と、追加の部分クラス コードも含まれています。
この問題に取り組んだ人はいますか? また、どのような提案をしますか?
名前空間の設定を活用してください。ORM の空白をクリックすると、プロパティでアクセスできます。
これにより、1 つの一連のビジネス ルールに対して Users テーブルと User クラスを使用し、別の一連のビジネス ルールに対して 2 つ目の (ただし同じデータ ストア) Users テーブルと User クラスを使用することができます。
または、会社の命名規則に応じて名前空間を変更する影響もあるはずのライブラリを分割します。すべてのテーブルにアクセスする必要があるエンタープライズ アプリに取り組んだことはありません。
私もツールを書きました！Mineは、c＃を使用してdbmlファイルへの変更をスクリプト化するためのものであるため、変更を失うことなく再実行できます。私のブログhttp://www.adverseconditionals.comを参照してください。4詳細
一定のサイズを超えると、dbml デザイナーではなく xml で作業する方がおそらく簡単になります。
2つの.dbmlファイルを保持するために使用したアプローチ。それらの1つはストアドプロシージャを保持し、すべての本番DBアクセスはこれを介して行われます。もう1つは単体テストフォルダーにあり、テーブルとその関係を保持し、DBデータの操作と単体テストのクエリに使用されます。
私はまさにその問題に対処するためのユーティリティを作成しました。必要なデータベース オブジェクトのみを選択できる簡単なアプリが必要でした。私の場合、複雑なビューが必要になることがよくありましたが、テーブルは必要ありませんでした。