なぜ失敗した結果を返すのではなく、重複したユーザー名が使用された場合、UserManage.CreateAsyncがEntityValidationErrorをスローしますか？

Question

私は以下の登録方法を持っています。私は（手動で）これをしばらく前にテストして、ユーザー名が既に存在する場合、結果にresult.Succeededのfalse値があり、ModelStateにエラーメッセージを追加する（AddErrors（result）ヘルパーメソッドのビルドを使用して）。私はこのメソッド（Register(...)）がASP.NET mvc 5のボックスから出てきていると確信していますが、私はユーザー名を含むように変更したと思います（メールボックスはユーザー名として使用されます）。

public async Task<ActionResult> Register(RegisterViewModel model) 
{ 
    if (ModelState.IsValid) 
    { 
     var user = new ApplicationUser { UserName = model.Username, Email = model.Email }; 

     var result = await UserManager.CreateAsync(user, model.Password); 
     if (result.Succeeded) 
     { 
      await SignInManager.SignInAsync(user, isPersistent: false, rememberBrowser: false); 

      return RedirectToAction("Index", "Home"); 
     } 
     AddErrors(result); 
    } 

    // If we got this far, something failed, redisplay form 
    return View(model); 
} 

代わりに、現在、EntityValidationErrorがスローされ、キャッチされないエラーが発生しています。

私は単にこのエラーをキャッチして私の日に移動することができますが、正しい動作でない場合は、この問題が原因であるかどうかを確認したいと思います。

更新：

新しいMVCプロジェクトを作成した後、私は典型的な振る舞いは（重複ユーザ名が登録されている場合）CreateAsyncがresult.Succeededのための偽の値で結果を返す必要があることであることを確認することができ、 ModelStateに「Username is taken」というエラーメッセージを追加する必要があります。明らかに、私のコードや設定では何かが間違っていますが、私はどこから探検を始めるべきかを知っているわけではありません。それが助けになると、私は最近、自分のコードの他の場所でEntityValidationErrorsを見てきました。参照：Unable to SaveChanges on a db update. Weird lazy loading behavior possibly?

Answer 1

私自身の解決策が見つかりました。私が言及したように、私はユーザー名を含むようにユーザーを変更しました（オプションのメールを作成するだけでなく）。このタスクの一部には、カスタムユーザーバリデータークラスの作成が含まれていました。カスタムユーザーバリデーターのValidateAsyncメソッドでは、ユーザー名が既に存在していて（ユーザーに属していないかどうか）チェックするのを忘れていました。これと同じように：

async Task<IdentityResult> IIdentityValidator<TUser>.ValidateAsync(TUser item) 
    { 
     var errors = new List<string>(); 

     // ... 

     // Piece of code I have now added 
     var owner = await _manager.FindByNameAsync(item.UserName); 
     if (owner != null && !EqualityComparer<string>.Default.Equals(owner.Id, item.Id)) 
     { 
      errors.Add($"Username {item.UserName} is already taken"); 
     } 
     // End of code I added    

     // ... 

     return errors.Any() 
      ? IdentityResult.Failed(errors.ToArray()) 
      : IdentityResult.Success; 
    } 

私は私のために学んだ教訓は、検証がUserManagerのでCreateAsync方法で発生するアプリケーション層の検証との差であると考えています。 Appレイヤの検証の場合、エラーはそれ自体が正確に規定されたとおりに表示されます。そのバリデーションのレイヤーが省略され、DBが同じ制約に直面した場合、コンテキストが保存されると、独自のエラーがスローされます。この場合、少し不明瞭なEntityValidationError。