DataControllerでDynamic Dataみたいな

ASP.NET MVC Tip #4 - Create a Custom Data Controller Base Class - Stephen Walther on ASP.NET MVC これもありだな～、と思います。

Google App Engineでの開発っぽい。 DataControllerだけが大事なところなのにコード量がべらぼうに少なくて、なんか嬉しい。 Form 値はRequest.Form.Keysをforeachで取り出したのとエンティティのプロパティが同じなら(上手く言えないけどリフレクションで)書き換える感じで。エンティティそのままでViewData用のクラスなわけじゃないから、 System.Web.Mvc.BindingHelperExtensions.UpdateFromを使えないのかな(NewとUpdateで同じコード書いてるのか切ない部分)？

でもね、GetDynamicGetがカッコよすぎる。 IdentityColumnNameも主キーがintの項目を1つにするルールを貫けば(Railsとかそうだし)超絶便利な予感。 派生してるのがHomeControllerだからリソース名がHomeに思えるけど、そこはデフォルトのままいじってないってことなんだろうから気にしない。実際にはこのサンプルならMoviesControllerとかにするのがナウなヤングのRails風？

RESTfulじゃないけど「設定より規約」なところがいいっす！ 最近のお気に入りはDBのテーブル全てにEntryDateとModifyDateをDateTime型で作っておいて、DataContextクラスのSubmitChangesをオーバーライドして勝手に値を入れるようにすること。

    public override void SubmitChanges(ConflictMode failureMode)
    {
      ChangeSet changes = this.GetChangeSet();
      DateTime now = DateTime.Now;
      Action setNow = (entity, name) => {
        var etype = entity.GetType();
        var prop = etype.GetProperty(name);
        if (prop != null)
          prop.SetValue(entity, now, null);
      };

      // insert
      foreach (var entity in changes.Inserts)
      {
        setNow(entity, "EntryDate");
        setNow(entity, "ModifyDate");
      }

      // update
      foreach (var entity in changes.Updates)
      {
        setNow(entity, "ModifyDate");
      }

      base.SubmitChanges(failureMode);
    }

GetChangeSet()で追加・更新・削除それぞれの対象レコードを取得できるから、それを取り出して自動更新。エンティティの型は宣言しないでvarで。varと規約ベースの開発は最高っす！ ただ悩みもありまして．．．。

入力値の検証(Validation)をどこでやるのがいいのかってことなんですけどね、LINQ to SQLのEntityのpartial classでやると、確実にチェックではじけていいんだけど、タイミング的にはもう少し早い段階でやりたかったりする。ViewDataクラスにバリデーション機能をつけるのがいいのかな．．．。アプリケーションの制約と、データベースの制約とレイヤーが違うからそれぞれに必要なんだろうけど(例えばAと Bっていうカラムがあって、更新するときにどっちも空は嫌だけど、どっちも空でもDBでは問題なしとか)。 タイムリーにオノさんところで紹介されてたサンプル(SingingEels : ASP.NET MVC in the Real World)を見てみたけど、普通にコントローラでForm値を検証してるじゃんよ．．．。 こんな感じなのかな～(とりあえずTempDataに入れちゃうとロードバランサとかで無茶ぶりできなくなる)。

追記なんですけど。 ASP.NET MVC Tip #5 – Create Shared Views - Stephen Walther on ASP.NET MVC これまた面白いのが．．．。Tip #4の続きで今度はまさにDynamic Data。 コントローラ用のViewフォルダに、コントローラでView()するASPXがない場合の初期動作として、Sharedフォルダ使う動きをうまく生かして、すべてに共通のViewでページ生成。なので、インターフェイスを動的に作る必要があるからASPXのコードビハインドにコード書いてる。 全然気になんない！Scaffold！

フリーマーケット

何気に海外のドラマを見てる時にフリーマーケットのシーンがあって、テロップに「Flea Market」って書いてて初めてフリマの意味を知りました。

さて、DataContractJsonSerializer使ってますか？ かつて何でもありだったJavaScriptSerializerの次に出てきた標準クラスなんだけど、これを使おうとするときは基本型指定ですよね。

で、ASP.NET MVC Preview3になってからJSONをレスポンスに返すためControllerに新たにJsonResult Json(...)が定義されてますよね。 で、これってobjectを引数に渡すんだけど、型指定しないってことじゃないですか。もしやと思って、ソース見てみたんです。 そしたら．．．。

#pragma warning disable 0618   
 JavaScriptSerializer serializer = new JavaScriptSerializer();    
 response.Write(serializer.Serialize(Data));    
#pragma warning restore 0618    

こんなコードになってた。強引っすね。 いいのかな～。自分も使いたいんだけど、使っていいのかな～。 だってね、LINQ to SQLのデータモデルクラスをそのままJSONで扱いたいけど、DataContractじゃないし、DataMemberついてもないからそのままだと使えなくて、でもそのためだけに別クラス作るのも馬鹿らしいじゃないっすか。みんなどうしてるんだろう。

そしたらさ、ガスリー君(本物なのかな？)が言うんですよ。 First thoughts on ASP.NET MVC Preview 3 | Aaron Lerch 「The JavaScriptSerializer class is actually undeprecated in .NET 3.5 SP1. 」 って（．．．どういう意味？）。 使っていいのか！？いいのかガスリー君！？

MVCContribでRESTful

CodeProject: RESTful routing in ASP.NET MVC. Free source code and programming help こんなに簡単に．．．。

SimplyRestfulRouteHandlerを使えばいいよ！ってことですね。 そもそもMVCContribってなんですか？ってなもんです。

なので、ちょっとソースをダウンロードして確認(現時点でのダウンロードが55っていうのが人気の無さを物語ってる気がしなくもなくもないけど気にしない！)。 かゆい所に手が届く系のライブラリって感じ？

RESTfulを単純にHTTP Methodだけで考えれば、リソースに対してGET/PUT/DELETE/POSTでアクションを決定するようにすればいいよね。ってことはリソース=Actionじゃなくて、リソース=Controller。 でも、WebでHTMLをViewにする場合、入力ページ(新規と編集)もGETだからリソースのGETとかぶる。あと、コレクションのGETも。 そうなると少し面倒な感じがしなくもないけど、RoutingでうまいことなんとかなるのがASP.NET MVCのいいところ。 URIの設計をしてて思ったのは、URIのリソースをそのままコントローラと一致させないで、以下に内包したコントローラとして頭を切り替えるかが結構キモなんですね。

会社と社員を内包関係で表現すると /Companies/{companyId}/Employees/{employeeId}

だけど、それぞれがコントローラになるんですよ～。 てことは、個別にしてもいいじゃない？

/Companies/{companyId} /Employees/{employeeId}

でも、これだと所属を表現できないからヤダってこともあるでしょう(会社と社員じゃないサンプルの方がよかったね．．．)。 デフォルトアクションがそれぞれIndexだとしたら、CompaniesController.Indexと EmployeesController.Indexがそれぞれのコレクションリソースで、個別のリソースを取得するためにもうひとつModelアクションを定義。で、RoutingでうまくModelアクションにルーティングしてあげればうまいこと出来るよね。

GET /Companies → 会社一覧取得 GET /Companies/New→ 会社新規フォーム POST /Companies → 会社新規登録 GET /Companies/123 → IDが123の会社取得 GET /Companies/123/Edit → IDが123の会社編集フォーム PUT /Companies/123 → IDが123の会社更新 DELETE /Companies/123 → IDが123の会社削除

こうしたいって時のコントローラでのアクション。 ※前回書いたRESTfulAttributeがある前提。

[RESTful(Post="Create")]
public ActionResult Index(int? id) {...}

[RESTful(Put="Update",Delete="Destroy")]
public ActionResult Model(int? id)
{
 if (id.HasValue)
  return Show(id);
 else
  return New();
}

public ActionResult Update(int id) {...}
public ActionResult Destroy(int id) {...}
public ActionResult Show(int id) {...}
public ActionResult New() {...}

これをうまくRoutingでさばきます。

routes.MapRoute(
 "Companies-Model",
 "Companies/{id}/{action}",
 new { controller="Companies", action="Model" },
 new { id = @"[\d]+" }
);

routes.MapRoute(
 "Companies",
 "Companies/{action}",
 new { controller="Companies", action="Index" },
 new { action=@"[a-zA-Z]*" }
);

こうやって、2つのRoutingでひとつのコントローラに対する、ルーティングを登録すればIDのありなしをちゃんと１つのコントローラで処理できるから、なんて素敵にRESTful！ってなりませんかね。 ※正規表現はよしなに。

ROAなURIを考えた場合{controller}/{action}/{id}だとアクションがリソースになるけど、{controller}/{id}/{action}でコントローラをリソースにしちゃいましょうっていう。

/Companies/123/Employees/456   

とかのルーティング↓。

routes.MapRoute(
 "Employees-Model",
 "Companies/{companyId}/Employees/{id}/{action}",
 new { controller="Employees", action="Model" },
 new { companyId=@"[\d]+", id = @"[\d]+" }
); 

※コレクション部のルーティングも同じように。

イロイロ内包するならたくさん書くか、"/Employees"を"/{controller}"にしてあげる。 統一インターフェースでのアクセスは規約でアクションを決め打ちすることで最強になるでしょう。 全然MVCContribの話じゃないっすね．．．。

で、これを簡単にするのにMVCContrib。 Simply Restful Routing ここにあるように、アクション名を規約に通りにつければ、HTTP MethodとURIを見て、うまいことルーティングしてくれます。PUT/DELETEはブラウザから送れないので、そこはHidden で"_method"にメソッド名を入れてオーバーロードPOST。Railsっぽく。 どっちを使うかは気分次第で！