8

最近、オブジェクトを適切に破棄するために、MVC3 アプリケーションに変更を加えましたDbContext[1]。これは開発ではうまく機能しましたが、アプリケーションが実稼働サーバーにプッシュされると、AppPool がリサイクルされるまで持続する面白い例外が断続的に発生し始めました。例外は、私のカスタムのコードにまでさかのぼることができ、次のAuthorizeAttributeようになります。

System.InvalidOperationException: The 'Username' property on 'User' could not be set to a 'Int32' value. You must set this property to a non-null value of type 'String'.

System.InvalidOperationException: The 'Code' property on 'Right' could not be set to a 'String' value. You must set this property to a non-null value of type 'Int32'.

(データベース スキーマは次のようになります: ユーザー: [Guid, String, ...], Rights: [Guid, Int32, ...])

まるで「ワイヤーが交差している」ようであり、アプリケーションはデータベースからの結果を混同しています。Right結果を として実体化しようとしていますUser。

の破棄を管理するために、DbContextコントローラーごとのレベルでこれを格納するコードを追加しました。コントローラーが破棄されるときは、コントローラーも破棄DbContextします。私はそれがハックであることを知っていますが、AuthorizeAttributeは を介し​​て同じコンテキストを使用しますfilterContext.Controller。

DbContextこの邸宅でのオブジェクトのライフサイクルの処理に何か問題がありますか? 上記の交差例外が発生する理由について、論理的な説明はありますか?

[1] オブジェクトを破棄する必要がないことは理解していDbContextますが、最近、それがベスト プラクティスであると述べている多くの情報源に出くわしました。

編集（@MikeSWのコメントごと）

がスコープ内にある場合、AuthorizeAttributeを表す のプロパティがメソッドでDbContext設定されます。このプロパティは、後でメソッドで使用されます。OnAuthorizationAuthorizationContextAuthorizeCore

4

2 に答える 2

1

実際にコンテキストを破棄する必要がありますか?

Microsoft ADO.NET Entity Framework チームと連絡を取り合っている Jon Gallant によるこの投稿によると:

DbContext オブジェクトで常に Dispose() を呼び出す必要がありますか? いいえ

EF チームの開発者と話をする前は、私の答えは常に「もちろん!」という圧倒的なものでした。しかし、DbContext ではそうではありません。DbContext オブジェクトで Dispose を呼び出すことについて、宗教的である必要はありません。IDisposable は実装していますが、それを実装しているだけなので、特別な場合に安全策として Dispose を呼び出すことができます。デフォルトでは、DbContext が自動的に接続を管理します。

于 2014-02-27T12:17:35.250 に答える