自動生成されたPOCOエンティティ（EF 4.x Dbcontext Generatorテンプレートなど）のすぐ上に検証テンプレートを追加することは無意味ですか？テキストテンプレート（EF 4.x Generatorとして）とポコスの検証属性？
ツールを実行するたびに属性が消去されるためです。
私の質問は、自動生成されたポコスエンティティと、もう一方の検証属性の両方を維持する方法はありますか？
コードの最初のアプローチでは可能でしょうか？
私は実際にデータベースの最初のアプローチで自分のプロジェクトをサートし、自分のPOCOを自動生成しました。 .ttファイルを削除し、生成されたpocosを保持し、新しいフィールド、検証属性などを管理するコードを最初に使用することは可能でしょうか？ POCOの変更によってデータベーステーブルが更新されますか？
あなたの照明に感謝します。
ここにはいくつかの問題があります。まず、データモデルクラスに検証属性を配置しようとしていることです。これは、データオブジェクトをビューに直接渡していることを意味します。それがうまくいく間に、それをするのが推奨される方法ではありません。
代わりに、特定のビューに必要な情報のみを持つビューモデルが必要です。これらのビューモデルには、検証属性があります。ビジネス・ロジックでは、ビュー・モデルをデータ・モデルにマップします。
ただし、ビューでデータモデルを使用するように決められている場合は、「バディクラス」と呼ばれるものを使用して、メタデータクラスにバリデータを追加します。
http://hartzer.wordpress.com/2010/01/26/mvc-buddy-class/
あなたが最初のコードに行きたい場合は最後に、あなたは、コードファーストは最初の非常に異なるデータベースよりも働くことがわかります。生成されたエンティティを取得してコードファーストマッピングにマップすることもできますが、エンティティフレームワークパワーツールCTP1を使用してデータベースをコードファーストモデルにリバースエンジニアリングする方がずっと簡単です。
真に「コードファースト」アプローチを実行している場合は、「コードはボス」です。コードを更新するためにコードジェネレータを繰り返し実行するべきではありません.POCOを直接更新する必要があります。
もちろん、プロジェクトの開始時にdbからコードを生成するPOCOは意味があり、多くの作業を省くことができます。しかし、それを続けるつもりはありません - あなたが言及する問題が発生します。
「データベースの最初の」アプローチを実行したい場合は、dbを変更してください.POCOは二次的なものになります。誰が「上司」なのか混乱します。
"私は、（あなたが言うように）"ポコスを生成し、新しいフィールド、検証属性などを管理するためのコードを最初に使用することが理にかなっていると思います。
「POCOの変更によってデータベーステーブルが更新されるのですか？ - それはあなたがdbを再生成するように設定されていない限り、そうしてはいけません。
注：私はNHibernateのバックグラウンドであり、EFではなく、同じ概念が適用されます。
DBのリバースエンジニアリングの開始時に、コードジェネレータを実行すると便利です。そして、そのプロセスに頼り続けるのはあまり関係ない。 とにかく、codefirstがデータベースを再生成すると思われます。私はこの機能性を掘り下げなければならない。 –
@AntoineM - コードにはいくつかの方法がありますが、その1つは変更するたびにデータベースを再生成することです。最近リリースされた4.3バージョンでは、「Migrations」サポートと呼ばれるものがあり、データベースを再生成するのではなく修正するためのスクリプトを生成することができます。 –
私はクラスの仲間とメタデータを見ました。非常に助力に見えますが、私はそれをコード生成と組み合わせることができます（このアプローチに固執すれば）。時間をとっていただきありがとうございます。 –