3

MVCをフロントエンドとして使用するプロジェクト用のエンティティフレームワークを使用しています。そして私は、リポジトリパターンを使ってunitof作業パターンを実装しました。私はビジネスを扱うためにリポジトリの上にサービス層を持っています。私の質問は例外を処理する場所です。 プレゼンテーションレイヤーへのすべての例外を通過させてコントローラーで処理するか、最下位レイヤーを処理する必要がありますか?エンティティフレームワークの例外処理、repositoyパターンのMVC

答えて

3

一般的な考えは、UIにすべての例外を処理させることではなく、それは意味がありません。 ADO.NETで実装されたデータレイヤーがあるとします。ここでの一般的なパターンは、データレイヤー内のSqlExceptionsを処理してから、SqlExceptionを上位レイヤーが処理すべきより意味のあるDatabaseLayerExceptionにラップして、このパターンを一番上まで続けることで、InfrastructureException、ApplicationExceptionなど...

最後に、処理されなかったすべてのApplicationExceptionsを捕まえます(そして、すべての例外を多態性のために継承します)。未処理のすべての例外を特別なケースとしてキャッチして、それから回復する。

また、手動またはAOPを使用してロギングを使用することをお勧めします。オンラインで豊富なリソース(たぶんLog4Net?)を見つけることができます。

1

私は、これらのオプションを持っている任意の例外handeling戦略で考える:(インスタンスのサーバーがダウンしているため、しばらく待ってから再度試してください)

  • ので、例外を無視し、可能な場合は例外から回復する

    • それは十分に深刻ではありません。
    • バブルアップ。いくつか挙げるとthrow;またはthrow new Exception("message", InnerException);など、複数の戦略が存在します。

    最後に、例外をログ形式でログに記録したり、電子メールなどを送信するためのグローバルオプションがあります。これは上記の3つのオプションすべてには含まれていませんオプション。

    上記のように、アプリケーションの各レイヤーで、上記の3つの方法のどちらを使用して例外を処理できるかを自問する必要があります。それを元に戻すことができない、または無視できない場合は、最終的なクリーンアップと例外の表示を行うフレンドリなエラーページに上向きにバブルする必要があります。