asp.netmvc--modelフォルダーにモデルを作成することをお勧めします。これらのモデルをビューで使用し、サービスレイヤーを使用してモデルをEFモデルに「適応」させます。
または、別のアプローチを使用しましたか。このアプローチの問題は、ほとんどの場合、私の（自作の）モデルがEFモデルのコピー（乾燥していない）であるということです。
それで、誰かがあなたのビューでどのモデルを使用するかを私に説明できますか？それは非常に混乱しているからです。model / viewmodel /Entityframeworkmodel...。
解決 ：
答えてくれてありがとう、私は今、いくつかのことをリファクタリングしていると思います！
正しいアプローチは、ViewModelに異なるクラスを使用し、永続性（エンティティ）に異なるクラスを使用することです。通常の理由は、ビューに追加のデータ（たとえば、ドロップダウンに入力するデータ、一部のフィールドを無効にするデータなど）を送信したり、別の検証を使用したり、エンティティのサブセットのみを表示したりする必要がある場合が多いためです。
私は純粋主義者ではありません。ビューモデルがエンティティとまったく同じであることがわかった場合は、エンティティを直接使用しますが、ビューに追加情報が必要になったら、コードをリファクタリングします。ほとんどの場合、私はエンティティから始め、段階的な開発のためにビューモデルで終わります。
通常、View Modelsは Models フォルダーにあり、Domain Modelsは ORM Layer にあります。
ビューモデル（名前から）は、表示プロセスを支援するためだけに必要なオブジェクトの通常のモデルであり、永続性はまったくなく、ロジックが含まれている場合があります。
ドメイン モデルがビュー モデルと一致するという問題に直面した場合は、モデルを再設計するか、中間者なしでドメイン モデルを使用する必要があります。
私としては、標準の MVC 構造の Models フォルダーを削除し、すべてのビュー モデルを格納する ViewModels フォルダーを追加することを好みます。Ladislav が最初の反復で述べたように、これらのビューモデルはドメイン モデルからのエンティティの正確なコピーである可能性がありますが、徐々に大きくなり、大きく異なります。
まあ、それは意味がありません。私はこれに苦労していましたが、テーブル エンティティではないモデルが必要だと思います。このドメイン モデルを呼び出しました。その理由は、linq2sqlを使用している場合、ブリッジ/リンクテーブル（実際のエンティティではない）と複雑な計算を処理する必要があるため、テーブルエンティティで作成できないことがあります。 ? したがって、私のアプローチは、ViewModel <-> Model <-> Entity を持つことです