6

ASP.NET Web API アプリケーションを構築していて、次の構造を持っていると仮定します。

ここに画像の説明を入力

図からわかるように、ASP.NET Web API コアはドメイン サービス レイヤー (たとえば、 、 などMembershipServiceのメソッドを持つクラス) と通信し、サービス クラスは 1 つまたは複数のリポジトリと通信して操作を処理します。GetUsersCreateUser

サービス操作 (MembershipService.CreateUserメソッドなど) がいくつかの理由 (満たされていない条件、リポジトリによってスローされた例外など) で失敗することは明らかであり、これは私が疑問を持っている場所です。

サービスクラスは例外を処理し、以下のような何らかの結果オブジェクトを返す必要があると思いますか:

public class OperationResult {

    public OperationResult(bool isSuccess) : this(isSuccess) {
        IsSuccess = isSuccess;
    }

    public OperationResult(bool isSuccess, Exception exception) : this(isSuccess) {
        Exception = exception;
    }

    public bool IsSuccess { get; private set; }
    public Exception IsSuccess { get; private set; }
}

public class OperationResult<TEntity> : OperationResult {

    public OperationResult(bool isSuccess) 
        : base(isSuccess) { }

    public OperationResult(bool isSuccess, Exception exception) 
        : base(isSuccess, exception) { }

    public TEntity Entity { get; set; }
}

それとも、サービスメソッドはそのような例外を抽象化するべきではなく、例外を直接的または間接的にスローする必要があると思いますか (操作に固有の新しい意味のある例外タイプを作成し、スローされた例外をその内部例外として配置します)?

4

3 に答える 3

3

処理中は、例外を使用してください。

于 2013-01-07T19:51:47.407 に答える
2

例外を回避することに何の意味もありません。例外は正当な理由であり、主に使用するためにあります! 全体像を見てみましょう。エラー チェックの昔ながらの方法で例外メカニズムを変更しようとしています。この方法では、例外のすべてのメリット (エラー処理と通常のコードの分離、CallStack など) が失われ、何も得られません。

この状況で私が通常行うことは、サービス層で例外をキャッチし、それをカスタム例外に再ラップすることです (InnerException フィールドの元の例外への参照を使用して)。

于 2013-01-07T17:55:06.007 に答える
1

Microsoft の本から引用すると、Membership API の実装は、例外を処理して結果オブジェクトを返すのではなく、例外をスローするため、クライアントと API の両方を制御しない限り、これがベスト プラクティスであると考えます。

クライアントと API の両方を制御する場合は、結果オブジェクトまたはエラー メッセージを返すことを個人的に好みます。これは、実際の例外のソースに関する詳細情報をログに記録したいためですが、パスワードが正しくないなど、問題が発生する可能性のあるすべての例外は望んでいません。

この場合、ユーザーへの単純なエラー メッセージで十分です。実際の経験から、検証エラーが発生するたびに例外をイベント ログまたはログ ファイルに記録することは、実際に障害が発生しているかどうか、または単にユーザーの入力ミスであるかどうかを判断しようとする運用担当者にとって大きな負担です。 .

于 2013-01-07T16:37:14.980 に答える