Microsoft の Web サイトを見ていると、自己追跡エンティティの使用が推奨されなくなっていることがわかりました。
以下の各リンクは、STE を使用しないことを言及している MS リソースです。
Entity Framework チームが利用できるテンプレートを示します: EF Designer コード生成テンプレート
Microsoft が STE の使用を推奨しなくなった理由を知っている人はいますか?
Microsoft の Web サイトを見ていると、自己追跡エンティティの使用が推奨されなくなっていることがわかりました。
以下の各リンクは、STE を使用しないことを言及している MS リソースです。
Entity Framework チームが利用できるテンプレートを示します: EF Designer コード生成テンプレート
Microsoft が STE の使用を推奨しなくなった理由を知っている人はいますか?
(注:私はMSで働いていないので、これはすべてMSの公式声明と過去の歴史に基づく推測です).
あなたが投稿した最初の記事は、理由を説明していますが、明確ではありませんが、より良い代替手段を使用することを望んでおり、STE を修正または改善する意図はありません。マイクロソフトは、RDO やリモーティング、LINQ2SQL と同様に、STE を「初期の失敗した実験」のビンに入れています。
一般に、Microsoft は、STE が実際のビジネス上の問題を解決するための最初の試みであるが、明らかに不完全であることを常に認めていました。特に、オブジェクト グラフを共有エンティティにアタッチするのが非常に苦手で、遅延読み込みをサポートしておらず、その他にもさまざまな制限がありました。
MS は、それらをクリーンアップしようとしないと決定したようです (同様の理由で、POCO テンプレートも非推奨になっていることに注意してください)。テンプレートを修正または改善する予定がないため、新しいプロジェクトでの使用をやめて、より優れた代替案に移行することを望んでいます。
DbContext ジェネレーター
このテンプレートは、単純な POCO エンティティ クラスと、DbContext から派生するコンテキストを生成します。以下にリストされている他のテンプレートのいずれかを使用する理由がない限り、これが推奨されるテンプレートです。
STE は主に、特にシリアル化シナリオ (WCF や Web サービスなど) で、エンティティが切断されてコンテキストに再接続されるケースをサポートするために存在しました。「標準」の Entity Framework オブジェクトでは、変更の追跡はすべてコンテキスト内で行われ、既存のエンティティをコンテキストに関連付けるには問題がありました。STE はそのプロセスを容易にしましたが、他のほとんどすべてを非常に困難にするという代償を払いました。
私が見て経験したことから、この問題を解決するためのより良い代替手段であると思われますが、STE が行ったことを実際に再現するDbContext
ものではありません。EF のヘビー ユーザーの間での一般的なコンセンサスは、EF エンティティをエンド ツー エンドでシリアル化することは非常に悪い考えであるようです。代わりに、DTO や AutoMapper などを使用して、DTO オブジェクトと EF オブジェクトをマッピングする必要があります。
STE の代わりに Trackable Entities を作成しました: https://trackable.codeplex.com。これは、NuGet パッケージと Visual Studio 拡張機能のセットとしてデプロイされます。ASP.NET Web API スキャフォールディング用の T4 テンプレートと、WCF サービスを生成するためのアイテム テンプレートを含む一連のプロジェクト テンプレートがあります。
これは、TE と STE を比較して書いたブログ投稿です: http://blog.tonysneed.com/2013/11/18/trackable-entities-versus-self-tracking-entities。
乾杯、トニー・スニード