アプリケーションに登録ページがあります。3 つの状態と 1 つのエラー状態 (エラーが発生した場合) があります。
- 基本情報の入力
- パッケージを選択
- 感謝を言います
- エラー
ここで状態パターンを使用したいと思います。最初に、問題のないコンソール アプリケーションを作成しました。MVC アプリケーションにこのロジックを実装したいのですが、構造について混乱しています。必要なビュー、モデル、およびコントローラーの数と、ロジックを配置する場所を意味します。
アプリケーションに登録ページがあります。3 つの状態と 1 つのエラー状態 (エラーが発生した場合) があります。
ここで状態パターンを使用したいと思います。最初に、問題のないコンソール アプリケーションを作成しました。MVC アプリケーションにこのロジックを実装したいのですが、構造について混乱しています。必要なビュー、モデル、およびコントローラーの数と、ロジックを配置する場所を意味します。
1 コントローラ:RegistrationController
6つのアクションメソッド:
これはあなたの心を動かすための大まかなコードです:
public class RegistrationController : Controller
{
public ActionResult Index()
{
RegistrationState model = RegistrationState.Init();
// just display the "Fill Basic Info" form
return View(model);
}
[HttpPost]
public ActionResult Index(RegistrationState data)
{
// process data and redirect to next step
this.TempData["RegState"] = data;
if (!this.ModelState.IsValid || data.State == State.Error)
{
// error should handle provided state and empty one as well
return RedirectToAction("Error");
}
return RedirectToAction("Package");
}
public ActionResult Package()
{
RegistrationState data = this.TempData["RegState"] as RegistrationState;
if (data == null)
{
return RedirectToAction("Error");
}
// get packages and display them
IList<Package> model = this.repository.GetPackages();
return View(new Tuple.Create(data, model));
}
[HttpPost]
public ActionResult Package(RegistrationState data)
{
// process data blah blah blah
}
// and so on and so forth
....
}
ご覧のとおり、状態の変化に対応するために、MVC 関連のコードを記述する必要があります。私の例では、すべてがアクション メソッドで行われます。ただし、アクション フィルターも使用できます。多くの異なる状態オブジェクトを提供できる一般的なアクション フィルターを考え出すことができない場合は、アクション メソッドでコードを記述することをお勧めします。
Asp.net MVC が十分に優れていることを知っている場合は、これをさらに一歩進めて、ある意味でルーティングと共に機能するステート マシン ControllerFactory を次のように記述できます。
{StateObjectType}/{State}
したがって、ControllerFactory は、ビュー データを既知の状態オブジェクト タイプに解析し、実行を特定のアクションに渡すことができます。州による。これにより、Asp.net MVC アプリケーションに適した特別なステート マシンになります。
もちろん、より重要な問題は、このパターンでアプリケーション全体を作成できるかどうか、またはこのように機能する特定の部分だけがあるかどうかです。もちろん、両方のアプローチを組み合わせて、それぞれに適切なルーティングを提供することもできます。
エラー状態を定義する方法には十分注意する必要があります。無効なフィールド データを入力してもエラー状態になるのではなく、実際には無効なデータを含むフィールドの横のビュー内に表示されるデータ検証エラーが発生するためです (つまり、無効な日付が 13 として提供されます)。 /13/1313)。エラー状態は、ユーザー入力に関連しない実際のオブジェクト状態エラーにのみ使用する必要があります。それがどうなるかは、私の想像を超えています。
私のコメントで述べたように、Asp.net MVC の紹介ビデオをチェックしてください。Asp.net MVC で検証がどのように機能するかがわかります。また、かなり単純なもの。
この種の状態パターンは、通常の Asp.net MVC 開発者が使用するものではありません。通常のアプローチよりもコードが複雑になる可能性が高いためです。決定する前に分析してください。Asp.net MVC は非常にクリーンなコードであるため、抽象化を追加すると混乱する可能性があります。また、ドメイン モデル (状態クラス) は、データ アノテーションを含む単純な POCO として、はるかに複雑なコードを持つ可能性が最も高いでしょう。
あなたの場合、状態によって異なる可能性がある状態に従ってオブジェクトを検証する必要があるため、データの検証もより複雑になります(データ注釈と一緒に使用する場合)。POCO オブジェクトは常に同じように検証されます。これは、より多くのクラスを使用できることを意味する場合がありますが、それらはより小さく、よりシンプルで、保守が容易です。
あなたは州を混乱させていると思います。状態の例は次のとおりです。
これらの状態のそれぞれにページがあります。
一部のフィールドを空のままにしたためにユーザーが登録できない場合、それらは最初の状態になり、いくつかの検証メッセージを表示する必要があります。
このため、最低限として、Register というコントローラーと次のアクション メソッドを用意します。