3

私は、.NET アーキテクトの第一人者である上級開発者と一緒に働いています。私たちは過去 6 か月以上にわたって多くの建設的な議論を行ってきましたが、通常、私はほとんどの議論で敗北を認めています。私は彼と一緒に仕事をすることでスタックを学びました。しかし、私たちが現在同意していない設計上の問題が 1 つあります。彼は私に彼の立場を納得させることができていないので、意見や提案が欲しいです。誰かが私が間違っています。

Entity Framework 4.0 を使用し、さまざまなモデルで持続性認識と自己追跡エンティティの両方を使用しています。Silverlight アプリケーションへの WCF ワイヤを介してシリアル化/逆シリアル化したエンティティ グラフへの変更を追跡するために、Self Tracked Entities の使用を開始しました。それは素晴らしく機能します。また、WCF 全体で使用していないモデルに Self Tracked Entities の使用を開始しましたが、多くは永続的な認識エンティティ/モデルのままです。

私の同僚は、Entity Frameworks ObjectContext は可能な限り短い時間だけ保持する必要があると考えています。彼は、クエリを実行するのに必要な時間と、何かを永続化するのに必要な時間だけ存在するべきだと主張しています。エンティティで行われるすべてのビジネス作業は、切り離して行う必要があります。エンティティ モデルごとに、IDisposable であり、インスタンス スコープで ObjectContext を持ち、メソッドにクエリ/永続化ロジックを持つクエリ クラスと永続クラスがあります。ビジネス ロジックで ObjectContext を直接使用するのではなく、これらのクエリ/永続化クラスをビジネス ロジックで使用します。これらのクラス インスタンスが構築されると、ObjectContext が構築され、Disposed されると、ObjectContext が Disposed されます。

まず、非セルフ トラッキング エンティティについて考えます。

彼がこれを望んでいる理由と、長時間実行される ObjectContext を持たないことを望んでいることは理解していますが、私の問題は、彼が常に些細なビジネス ロジックでさえも ObjectContext から分離することを望んでいることと、設計の下に別のクエリと永続化コンテキストがあるという事実です。ビジネス ロジックで使用されているエンティティの ObjectContext 状態追跡がないことを意味します。非セルフ トラッキング エンティティの場合、これは、ビジネス ロジックでエンティティを変更する場合、永続化する前に手動でエンティティの Modified 状態を設定する必要があることを意味します。複数の変更を伴う複雑なグラフを永続化する場合、これは非常に苦痛です。また、EFが自動的に行うのと同じように手動で行うこともできないと思います。

セルフ トラッキング エンティティの場合、この状況は同じです。なぜなら、トラッキングはグラフが逆シリアル化されたときにのみオンになるためです。そのため、クエリが実行され、コンテキストから切り離されたサービス内で作業している場合、セルフ トラッキング エンティティでのトラッキングはまだ行われていません。 .

私の質問は、Entity Framework を使用するためのベスト プラクティスは何ですか? また、Entity Framework DAL はどのように設計する必要がありますか? ObjectContext はどのくらいの期間存在する必要がありますか? ビジネス ロジックは常に ObjectContext から切り離して実行する必要がありますか? もしそうなら、ObjectContext から切り離して作業しているときに、どのように状態追跡を行うのでしょうか? 私が考えている 1 つのオプションは、すべてのエンティティを Self-Tracked Entities に変換し、いくつかのグラフ トラバーサル コードを使用してクエリされたグラフをトラバースし、グラフ内のすべてのエンティティの追跡をオンにして、サービス側で作業しているときでもセルフ トラッキングがオンになるようにすることです。 (基本的に、Self-Tracked Entities グラフが逆シリアル化されたときに何が起こるかを模倣します)...

ObjectContext を長期間保持することを提案しているわけではありませんが、クエリと永続性の間で切り離された作業を行って、ObjectContext の状態追跡の利点を失うことはばかげているように思えます...EntityFramework の大きな利点の 1 つを失っています。 ..

長い投稿で申し訳ありません...助けていただければ幸いです。

4

1 に答える 1

4

Microsoft は、ObjectContext の存続期間を短くすることを推奨しています。私の経験から、ObjectContext の存続期間は、理想的には、Web 要求/ユーザー操作の期間と相関する必要があると考えるようになりました。

デスクトップ アプリケーションでグローバルで長寿命の ObjectContext を使用しようとしたのは間違いでした。それは完全な惨事でした。キャッシング、under/redo 編集セマンティクスなどを実装する場合は、基になるデータ エンティティから明確に分離された ViewModel クラスを使用する設計を検討する必要があります。EntityFramework を使用して Model オブジェクト グラフを作成し、そこから ViewModel を作成します。変更を保存する場合は、ViewModel リポジトリが基になるエンティティに再接続し、プロパティを変更して変更を保存できるようにします。これにより、より「キャッシュ可能」で柔軟な、ORM に依存しない、単体テストに適した設計が可能になります。

変更の追跡に関しては、UI の安価な「ユーザーが変更を加えた」メカニズムとは考えないでください。むしろ、変更を保存するときにどの最近作成されたエンティティを考慮する必要があるかを追跡するための高価なメカニズムと考えてください。

于 2010-09-29T08:54:03.557 に答える