3

たくさんのコードをAccountControllerプロバイダーAuthenticationクラスにリファクタリングしました。このチェックを実行するために使用されるコントローラー：

if (_memberRepository.GetByUserName(model.UserName) != null)
{
    ModelState.AddModelError("", "The user name you have chosen already exists. Please choose another.");
    return View(model);
}

これをクラスに移動しましAuthenticationたが、にアクセスできませんModelState。

if (_memberRepository.GetByUserName(newMember.LoginName) != null)
{
    // Panic stations!!
}

するべきか：

a）新しいメソッドのステータスまたは結果を記述したクラスを返しますか？これは物事を複雑にしすぎているように感じます。b）重複するユーザー名を登録することに異議を唱えることを示す例外（おそらくArgumentException？）をスローしますか？これは迅速かつ簡単ですが、ビジネスロジックの例外を使用することに国境を接しています

すでに存在しているMembershipCreateUserExceptionようですが、組み込みのメンバーシップ機能を使用しないようにしたいと思います。OOは良くなく、使っていると汚れてしまいます。

4

4 に答える 4

2

簡単な答え：入力検証は決してスローされるべきではありません。

長い答え：「選択したユーザー名はすでに存在します」は、予想される予測可能な種類のエラーであり、スローせずに適切に処理する必要があります。ログイン時の間違ったパスワードと違いはありません。たとえば、データベースに到達できなかったために新しいユーザーを作成できなかった場合は、例外をスローする必要があります。

それでも、例外を介して物事を機能させることができる場合があります。これはベストプラクティスの問題です。

于 2012-07-02T06:43:08.583 に答える
1

outエラーメッセージが表示される可能性があります。または、名前が使用可能かどうかを確認するだけの簡単なメソッドをプロバイダーに追加します（名前が非同期で呼び出される可能性があります）。次に、名前チェックの動作を登録ロジックから分離したので、関係する必要があるのはユーザーを追加することだけです。

于 2012-07-02T06:34:08.457 に答える
1

このケースは例外的であり、私は例外をスローすることにします。ステータスクラスまたはoutパラメータを毎回チェックすることは、私（およびオールドスクール）にとってはるかに汚いようです。一般的なケースのコードを記述し、例外を除いて例外的なケースを処理する方がクリーンだと思います。

于 2012-07-02T06:41:27.407 に答える
0

この条件（ユーザー入力の検証）を予期しているため、例外が間違っているように見えます。

この名前のユーザーの存在を確認するだけの別のメソッドを作成します。

既存のメソッドの名前を変更して、ユーザーが存在しない場合に特別な（null？）値が返されることを明確にすることができます。

于 2012-07-02T06:44:05.233 に答える