0

NerdDinnerチュートリアルのステップ5で、完全な編集アクションメソッドの実装の途中に次の段落があります。

Edit実装の良いところは、ControllerクラスもViewテンプレートも、Dinnerモデルによって適用される特定の検証またはビジネスルールについて何も知る必要がないことです。将来、モデルにルールを追加することができ、それらをサポートするためにコントローラーやビューにコードを変更する必要はありません。これにより、最小限のコード変更で、将来的にアプリケーション要件を簡単に進化させる柔軟性が得られます。

私の質問は、どのようなルールが追加される可能性があり、クリーンな分離を失わないようにするかです。私はこのコードを見ることができます：

 public static class ControllerHelpers {

   public static void AddRuleViolations(this ModelStateDictionary modelState, IEnumerable<RuleViolation> errors) {

       foreach (RuleViolation issue in errors) {
           modelState.AddModelError(issue.PropertyName, issue.ErrorMessage);
       }
   }
}

このコードよりも優れています：

catch {
    foreach (var issue in dinner.GetRuleViolations()) {
        ModelState.AddModelError(issue.PropertyName, issue.ErrorMessage);
    }

    return View(dinner);
}

特定のクラス/モデル情報がなく、アプリケーション全体で使用できるためです。そして、私のエラー処理が上記のように単純である場合、それがどのように良いかはわかりますが、新しいビジネスルールにもっと複雑なものを追加する方法がわかりません。例を期待していました。

4

1 に答える 1

0

まず、投稿したコードが実際にはModelからエラーを「プル」し、（ModelStateを介して）ビューに配置することを理解してください。柔軟性は、新しいルール/編集がモデルに触れるだけでよいという事実にあります。つまり、Dinner.csコードを押すだけです。

NerdDinnerのレッスンで理解しなければならなかったことの1つは、Dinner.cs OnValidate（）部分メソッドとUpdateModel（）の呼び出しのDinnersController.csの両方で検証が行われることでした。この呼び出しは、画面からモデルにテキストをコピーします。たとえば、テキストをfloatにコピーしようとすると、ModelStateが更新され、エラーがスローされます。通常の検証は実行されません。

于 2009-10-23T15:40:41.733 に答える