3

UI、サービス層、およびリポジトリ層を備えた ASP.NET Web フォーム アプリケーションがあります。

サービス レイヤーのメソッドの一部はWeb サービスと通信するため、Web メソッドへのすべての呼び出しをTry-Catch-Finallyコンストラクトでラップしたいと考えています。

Service Layerに次のメソッドがあるとします。

public RegistrationDetails GetRegistrationDetails(int userId)

public bool RegisterUser(UserData myUserData)

RegistrationDetailsとはオブジェクトmyUserData型 (クラス) です。

私の懸念は次のとおりです。Try-Catch-Finally上記のメソッドの実装内で Web サービスへの呼び出しをラップする を作成した場合、例外が発生した場合、戻り値の型がRegistrationDetailsおよびの場合、どのようにメッセージ文字列を返すことができboolますか?

すべての戻りオブジェクトにプロパティを追加することを考えていましたが、それが良い解決策かどうかわかりません。たとえば、使用する代わりにbool:

public class RegisterResponse
{
   public bool isRegistered { get; set; }
   public string ExceptionMessage { get; set; }
}

public RegisterResponse RegisterUser(UserData myUserData)

そして、ExceptionMessage がnullまたはであるかどうかを確認しますString.Empty。それは良いアプローチですか？ありがとう

4

2 に答える 2

0

サービスからクライアント (Web フォーム層) に生の例外を渡すことは危険です。データベースの例外である場合は、データベースの詳細が公開される可能性があります。悪意のあるユーザーが、自分のアプリケーションからサービス レイヤー メソッドを呼び出す可能性があります。

クライアント レベルでは、次の 2 種類の例外が予想されます。

  1. 通信例外 (サービスへの接続の問題)
  2. サーバー側のエラー (データベースの問題、ユーザー名が一意でない、パスワードが無効... その他のビジネス ルールの例外)

最初のタイプは Web フォーム レイヤーの try-catch-finally でキャッチする必要がありますが、2 番目のタイプはサービス レイヤーでキャッチし、ログに記録してからRegisterResponseオブジェクトにラップする必要があります。ただし、Exception.Message を送信する代わりに、予想されるエラーの列挙型を使用することを検討することもできます (それ以外は ServerError メンバーでカバーします)。エラーを調査できるように、応答とログ エントリに EventId を追加することもできます。

public enum RegisterResponseError { NoError = 0, SystemError = 1, 
    UserNameNotUnique, PasswordInvalid, etc.  }

public class RegisterResponse
{
   public bool isRegistered { get; set; }
   public RegisterResponseError ErrorCode { get; set; }
}

次に、クライアント コードで、

if(myRegisterResponse.ErrorCode == RegisterResponseError.NoError)
   // everything was fine
else
  // show a suitable error message for ErrorCode and display EventId (if logging)

サービスからエラー文字列を返すこともできますが、後でコンテンツをローカライズしたり、CMS を使用したりする必要がある場合に備えて、Web フォーム レイヤーでコンテンツを管理することをお勧めします。

于 2012-06-04T17:58:01.863 に答える