4

MVC3 Web アプリケーションで Entity Framework 4.1 を使用しています。私は、約 200 以上のテーブルを持つデータベースを使用してレガシ アプリケーションを書き直す任務を負っており、既にデータが配置されているため、EF でデータベース ファーストのアプローチを採用しています。

アプリ全体に対して 1 つの巨大な edmx モデルを作成するのは悪い習慣であることは理解していますが、何時間もの調査の後、共通テーブルを再利用する方法がわからないため、前進する方法について明確な方向性を得ることができません。複数のモデルで。しかし、モデルをより小さく、扱いやすいコンテキストに分割したいと考えています。

2 つのモデルに共通テーブル (Users など) を配置すると、プロジェクトは次の形式でコンパイル エラーをスローします。

タイプ 'Project.Models.EntityX' には既に 'EntityX_PropertyY' の定義が含まれています

私が見つけた回避策に最も近いのは、http: //connect.microsoft.com/VisualStudio/feedback/details/366721/entity-framework-the-type-xxx-already-contains-a-definition-for-です。バツ

Microsoft によって 2008 年 9 月 17 日午後 5 時 18 分に投稿されました。

この問題は仕様によるものです。回避策は、モデルを別のフォルダーに配置するか (C# および ASP.NET プロジェクトの場合)、カスタム ツールの名前空間を設定することです (C# および VB プロジェクトの場合)。

これは'08年にさかのぼります。どちらのオプションも機能しませんでした。複数のモデルで同じテーブルを使用できるようにプロジェクトを設計するためのより良い方法があるかどうか疑問に思っています。

4

3 に答える 3

3

私たちのチームは、プロジェクト (最大 600 テーブル) のこれらすべての投稿を確認しました。ここでの私の回答に対する大きな注意点は、プロジェクトはまだ完了していないため、すべての学習が行われたわけではないということです。これまでに学んだことしか提供できません。

基本的に、あなたがやりたいことは現実的な方法では不可能です（現在、私が知っていることです）。

私たちの要件は、ビジュアル デザイナー (必ずしも Visual Studio デザイナーである必要はありません) を使用できることであり、自動生成された一連のファイルをハッキングする (またはファイルを自動的にハッキングするツールを作成する) 必要がないことでした。いろんな意味で災害に。

私たちが本当に望んでいたのはテーブルの論理的なグループ化であることに注意して、2 つの可能な解決策に行き着きました。

  • テーブルをデータベースの異なる「ビュー」に論理的に分離できるLLBLGenのデザイナーを使用します(注: 商用利用は無料ではありません)。

  • テーブルをビジネスベースのサブセット (つまり、販売、レポートなど) に分割し、重複するテーブルは異なる名前を使用して繰り返し、各サブドメインで異なる列のセットを使用する可能性があります。

テスト段階では、LLBLGen のデザイナーがとても気に入りました。ただし、コード生成オプションは目まぐるしく (間違いなくプログラマーがプログラマーのために書いたものです)、出力には多くの要望が残されていました (私の最初の試行では、コンパイルされないコードが生成されました)。プロジェクトに数ドルを投資してテストに時間を費やしても構わないと思っている場合でも、自分で試してみることをお勧めします (無料試用版があります)。先ほども言いましたが、デザイナーはとてもいい人で、ネットで調べてみると、成功例がたくさんあるようです。

言うまでもなく、後者のソリューションを選択しました。私たちのビジネス モデルでは、「共有」テーブルがある場合、1 つを除くすべてのサブドメイン モデルでこのテーブルが読み取り専用であり、すべてのサブドメイン モデル間で変更が伝達されることを心配していないため、これはうまくいきました (つまり、各サブドメインからのデータの特定のビューのみが必要です)。これはあなたにとって同じケースではないかもしれません。基礎となるスキーマに大幅な変更を加え始めると、余分なメンテナンス オーバーヘッドが発生しますが、レガシー データベースを使用しているため、おそらくそうはなりません。ツールを既存の開発環境内に維持することは、トレードオフの価値があると判断しました。(注: 軽く変更された POCO テキスト テンプレートを使用して、エンティティ クラス自体を生成しています。他に何もないとしても、この部分は本当に良い決定でした。)

わずか 200 個のテーブルしかないので、実験としても、すべてを 1 つのモデルにまとめてみてください。これには間違いなく最も強力な開発ボックスを使用する必要があります... モデル (EF 4.0) を使用してこれを試したとき、プロセスの途中で強制終了する必要がありました。

資料を読んでいるうちに、Visual Studio デザイナーでモデルの "ビュー" を直接サポートすることについて、不満がいくつか見られました。これが存在する場合、私たちは絶対にそれを使用します。ただし、現状では、そのような機能は後回しになっていると思います。200 テーブルのプロジェクトは、実際にはそのような機能を必要としない 100 テーブル以下のプロジェクトと比較して、間違いなくニッチです。

于 2011-07-19T23:17:16.983 に答える
2

簡単な解決策は、モデルのエンティティ名を変更することです。
エンティティの名前にプレフィックスとしてコンテキストを追加すると、問題が解決します。

于 2011-08-02T09:29:49.320 に答える
0

まだ試してみたい場合は、これを捨ててください。ただし、モデルを別のアセンブリに入れてみましたか？

例：MyProject.Data.Salesのモデル内のすべての注文テーブルMyProject.Data.Customersなどのモデル内のすべての顧客管理

それらは異なる名前空間にあるため、そのように衝突することはなく、必要な数だけ持つことができるはずです。使用する場合は、正しく参照する必要があります。

于 2011-08-02T10:12:35.653 に答える