2

Webアプリに対して実行しようとしているリファクタリングについての洞察と考えが必要です。

最初は、HttpApplicationでOn_BeginRequest / On_EndRequestを使用してセッションを作成および破棄することにより、NHibernateおよびActiveRecordでリクエストごとのセッションパターンを使用しました。後で、DB関連の例外がモノレールコンテキストの外にスローされたことに気付きました。つまり、レスキューが開始されませんでした。別の副作用として、NHibernateセッションの作成を完全にスキップするオプションがありませんでした。アクション。場合によっては望ましいでしょう。

そこで、ベースコントローラーのInitialize（）/ Contextualize（）でセッションを作成するように書き直し、ベースコントローラーのDispose（）にそれらを配置しました。また、レスキューコントローラーでセッションをロールバックして、DBへの半分の書き込み変更を防ぎます。ここまでは順調ですね。Dispose（）でこれを行う理由は、遅延読み込みの理由と、セッションを取得する必要のあるビューコンポーネント（ viewcomponentsですが、Dispose（）がないようです...）

ただし、DBでトランザクションを開始したときに、ロールバックもコミットもされていないデッドロックの問題が発生しており、主にこのアプローチで混乱が生じたために、頭を悩ませることができません。 。

だから私はこの記事を見つけました：http：//hackingon.net/post/NHibernate-Session-Per-Request-with-ASPNET-MVC.aspx

そして、「フィルター、MonoRailでも使用できます！」と思いました。BeforeActionとAfterRenderingを開始できるからです。

私の質問は次のとおりです。

  1. フィルタで例外が発生した場合はどうなりますか？
  2. アクションまたはレンダリングで例外が発生した場合でも、AfterRenderingは起動しますか？
  3. このアプローチをお勧めしますか？そうでない場合は、代わりにどのような提案をしますか？

どんなポインタでも大歓迎です！

4

1 に答える 1

1

  1. 例外処理を処理するには、アプリケーションエラーハンドラが必要です。

  2. デバッガーを接続して調べます。

  3. おそらくそうではありません（私の記事ですが）。RenderActionでは機能しません。IoCコンテナを使用して、接続の有効期間を制御するのが最適です。

于 2011-02-08T12:21:08.723 に答える