1

私はかなり長い間この考えを心に抱いていましたが、まだ答えが見つかりません。私の DbContext は UnitOfWork クラスによって処理されます。そのため、savechanges が発生する場所が 1 か所あり、これらの厄介な例外をすべてキャッチして、1 か所で処理しています。

しかし、広く知られているように、DbContext は、SaveChanges() メソッド以外の別の場所で、他の種類の例外をスローすることがあります。たとえば、エンティティを具体化するとき。しかし、これは多くの場所で発生する可能性があり、FirstOrDefault() または ToList() 呼び出しのたびに try catch ブロックを記述し、例外をキャッチして再スローすることはオーバーヘッドになる場合があります。この例外は、接続を開くことができないことを意味する SQL タイプ、EntityCommandExecutionException などである場合があります。

したがって、例外が発生したときに DbContext オブジェクトが発生するイベントがあるのではないかと思っていたので、そのイベントをサブスクライブして、これらのシナリオでいくつかのロジックを処理できます。:)

4

1 に答える 1

2

いいえ、ありません。そして、(少なくとも) 3 つの理由から、決してそうなることはありません。

  1. 例外は意図的にスローされる可能性がありますが、EF のソース コードのどこかで発生してバブルアップする可能性もあります。前者の場合はイベントを発生させることができましたが、後者の場合はできませんでした。だからあなたは決して安全ではありません。

  2. イベントはどのように発生させる必要がありますか? イベントをスローするには、いくつかの方法があります。そのうちの 1 つは、catch ブロックで再スローするだけです。eventcatch ブロックで を起動するのは非常に悪い習慣のように思えます。Catch ブロックには、安全で安定したコードを含める必要があります。catch ブロックで例外が発生すると、状況は悪化します。誰かが私の catch ブロックに何らかのコードを接続できるとしたら、非常に気分が悪くなります。

  3. イベントはいつ発生する必要がありますか? 一部の例外は、EF アセンブリ内でスローされ、処理される場合があります。おそらく、それらが発生したことを知りたくさえありません。しかし、別のシナリオでは、同じ例外が発生する可能性があります。

于 2013-04-05T14:30:04.977 に答える