1

境界モデルを検証するカスタム モデルバインダーを作成したいと考えています。これのいくつかの例を見つけましたが、正常に機能します。しかし、モデルにエラーがある場合、ユーザーを元のページに戻すこともできるようにしたいと考えています。

これを行うことは可能ですか?これを行うことによって明らかな副作用はありますか?

私が達成したいのは、コントローラーが常に有効なコマンドを取得することです。そのため、アクション メソッドで model.IsValid() をチェックする必要はありません。

4

1 に答える 1

3

あなたがやろうとしていることは良さそうに見えますが、うまくいきません。制限が多すぎます。

  1. 通常、エラーが発生した場合にリダイレクト先を決定できるのはコントローラーだけです。[OnError("Action")] のような追加の属性を使用できますが、これは回避策のようです。
  2. フォームはすべてのデータを投稿しません。たとえば、ドロップダウン リスト、補助値はコントローラーで入力する必要があります。これにはおそらくアクション フィルターを使用できますが、これもハックのように見えます。

モデル エラー (バインダー セット) とリダイレクト (setup .Result) をチェックするグローバル アクション フィルター (ベース コントローラー上) をセットアップできます。しかし、これは複雑で、追加の「コード」 (属性など) が多すぎるため、追跡して実際のアプリケーション ロジックに関連付けるのが難しくなります。そして、エラーリダイレクトなどの単純なアクション名だけが必要ではない場合、すぐに制限が厳しくなりすぎます（漏れのある抽象化の法則を参照）。

次のようにすると、これははるかに簡単に見えます。

public ActionResult PostAction(ViewModel data)
{
   if (!ModelState.IsValid)
      return View("GetAction", data.WithDropDownList(repository.GetProducts()));

}

上記の例では、本来あるべきように、コントローラーがワークフローを制御しています。また、追加の検証/セットアップを自由に実行できます。ModelState エラーを提供するためのモデル バインダーなど、可能な限り多くのインフラストラクチャを引き続き使用できますが、コントローラーのみが入力と出力に関する最終的な決定を行う必要があります。

于 2010-06-26T13:48:17.093 に答える