miso_soup3 Blog

主に ASP.NET 関連について書いています。

EFMVC より、コントローラのPOSTアクションメソッドの流れを追う

ASP.NET MVC

コントローラのPOSTアクションメソッドで、とても綺麗だな〜と思ったコードがありましたので、それについて書きます。
GETなアクションメソッドはまた別の話です。

そのコードは EFMVC で書かれているものです。

綺麗だな〜と思ったコード

コードはこれです。（EFMVCのコードを少し変更したものです。）

/// コンストラクタ
public CategoryController(ICommandBus commandBus)
{
    this.commandBus = commandBus;
}

[HttpPost]
public ActionResult Save(CategoryFormModel form)
{
    if(!ModelState.IsValid)
        return View(form);
　　
　　//作成コマンド 
    var command = new CreateOrUpdateCategoryCommand(form.CategoryId,form.Name, form.Description);
　　//検証
    IEnumerable<ValidationResult> errors = commandBus.Validate(command);
    ModelState.AddModelErrors(errors);

    if (!ModelState.IsValid)
        return View(form);
　　//実行
    commandBus.Submit(command);

    return RedirectToAction("Index");   
}

注目する点は、
コントローラーは、ICommandBusと、リクエストする内容、この２つだけを知っているだけでいい
ということです。

ＷＥＢアプリにおいてデータのコミットで重要なタスクとなるのは、

  • 検証
  • 実行
  • 次のページへ

この３つです。

これら３つの作業を、コントローラはICommandBusと、リクエストの２つだけで行っています。
コントローラが扱うものが少なくなると、テストの記述が簡単になりますし、
また、コードから何をしているのか確認しやすくなるという利点があります。

ICommandBusは全アクションメソッドで使えます。コピペ…コードの自動生成も楽ちんです。
そして、インターフェイスであり、名前の通り、コマンドのベルトコンベアみたいな役割を持っています。

つまり、コントローラは何をしているのかというと、
アクションメソッドに合うリクエストを作って、後はそのベルトコンベアにポイって投げているだけです。

ICommandBusがどのように実装されていて、ベルトコンベアがどこにいって、誰が実行しているのか、
モデルの設計がどのようになっているか、記載していきます。

コードの場所

コードは EFMVC からDownloadできます。

順番に追っていきます

先ほどのコードを例に追っていきます。

コマンドの作成
[HttpPost]
public ActionResult Save(CategoryFormModel form)
{
    if(!ModelState.IsValid)
        return View(form);

    var command = new CreateOrUpdateCategoryCommand(form.CategoryId,form.Name, form.Description);

実行するためのコマンドクラスを作成しています。
フォーム送信データ　→　実行コマンド　へのマッピングみたいなものなので、Automapperで行うのもありだと思います。

検証
IEnumerable<ValidationResult> errors = commandBus.Validate(command);

ICommandBusのValidateメソッドにコマンドを渡し、検証結果を受け取っています。
（このValidationResultは、EFMVC.Coreプロジェクトにある検証結果をもつクラスですが、
DataAnnotationのValidationResultでも良いと思います。）

ModelState.AddModelErrors(errors);

そしてその検証結果を、拡張メソッドを利用してModelStateに追加しています。
これも、モデルの検証結果　→　コントローラのModelState　というマッピングの１つだと思います。

検証の流れは以上です。

次は、実際に実装している部分を追います。

ICommandBusと検証の実装クラス

ICommandBusのValidateメソッドの呼び出し先は、
ICommandBusの実装クラス、EFMVC.CommandProcessor.Dispatcher.DefaultCommandBusクラスです。
DefaultCommandBusでは、指定された型に合う実装クラスを取得＆実行します。
つまり、渡されたリクエストに合う、検証クラスを呼び出して実行します。

Validateメソッドが呼ばれた時に、>　を実装するクラスを
MVCのDependencyResolverから取得します。取得されるクラスは、今の場合は
>の実装クラスである、EFMVC.Domain.Handlers.CanAddCategoryクラスです。

MVCのDependencyResolverから、実装クラスが取得できるようにするためには、
事前にIoCフレームワークのAutofacを使って、独自DependencyResolverをMVCに登録する必要があります。

場所は、EFMVC.WebプロジェクトのBootstrapperクラスです。

Interfaceと実装クラスのマッピングを設定した後の１番最後にある、
DependencyResolver.SetResolver(new AutofacDependencyResolver(container));
これです。（最近こればっかり書いているような・・・）

DefaultCommandBusクラスは、EFMVCではMVCのDependencyResolverを利用して実装していますが、
DependencyResolverを使わなくても実装できます。
UnityのIServiceLocatorを利用したり、自分でインスタンスを取得したり、自由に実装できます。要は具象クラスを呼び出せられればＯＫです。
私の場合はStructuremapを利用しているので

T handler = ObjectFactory.GetInstance<T>();

と書いています。

実行
commandBus.Submit(command);

実行も、検証の流れとほぼ同じです。
ICommandBusのSubmitメソッドにコマンドを渡しています。
（Submitメソッドは、boolを返していますが、意味がないのでvoidが良いと思います。）

検証は>でしたが、
実行の時は、>を呼び出しています。

実行後

実行後は、return View();でページ遷移です。

POSTアクションメソッドの流れは以上になります。

コントローラのPOSTアクションメソッドについて

以上、EFMVC　より、POSTアクションメソッドの流れを追ってみました。

今一番試してみたい設計ですが、クラスの数が大量にならないかな〜という心配があります・・・。
でも、検証＆実行は頻繁に使う流れなので、ICommandBusでまとめたいところです。
１つのリクエストを検証メソッドと実行メソッドの２つに通す、というのも綺麗です。

コントローラのPOSTのモデルは、そんなに複雑にならないので、そんなに凝らなくても大丈夫かな〜と思いますが…。
（検証ロジックと実行ロジックがまとまっていれば！）

問題は、GETです。
ViewModelの組み立てが大変で、現状問題ありありです。解決策はまだ見つかっておりません(+_+)

おまけ　CQRSパターンについて

EFMVCは、CQRSパターンを利用しています。
”クエリ（取得）”と”コマンド（実行）”を、それぞれ独立した責務として明確にモデル化するというものです。
なので、取得はRepositoryに、コマンドはHandlerと別々になっています。

CQRSパターンについては
Windows Azure での CQRS
Greg Young流CQRS - Mark Nijhof
副作用を最小限に抑えるために必要なこと
に説明が載っています。（難しくてわからなかった…）