AngularJS の $resource + ASP.NET WebAPI における、データ (エンティティ) の新規追加処理

前回の投稿にて、AngularJS の $resource サービスと ASP.NET WebAPI の組み合わせについて言及し、いわゆる "CRUD" 処理における、Read、Update、Delete について説明した。
(すなわち、query メソッドと、エンティティに生える $save、$remove メソッドを使えばOK、という話題)

AngularJSの$resourceとASP.NET WebAPIとの組み合わせサイコーなのでさらにTypeScriptも混ぜたい件
http://devadjust.exblog.jp/21257454/

しかしながら上記投稿では、エンティティの "C"reate 処理、すなわち新規追加の手順について明記していなかったので、今回の投稿で補足する。

AngulaJS でフォーム入力からサーバーに送信するまで

前回投稿の例を引っ張るが、たとえば新しい Book の追加処理を実装する場合、まずは UI 上のフォームに入力された結果を AngularJS の力をもって、JavaScript オブジェクトとして $scope のメンバにバインドすることだろう。

// newBook == {title:'(title)'}

var newBook = $scope.newForm.book;

これをサーバー側に XHR POST したいわけだが、もちろん、生の XHR 呼び出しを記述することなく、そこは AngularJS の力でスマートに記述したいところだ。

だが上記例における変数 newBook に格納されているオブジェクトは、何の変哲もない素の JavaScript オブジェクトだ。

$resource サービス経由でインスタンス化したエンティティと異なり、$save() といった便利なメソッドは生えていない。

さて、どうやって、この新規追加処理を扱えばよいのか?

$resource サービスから返された "リソースクラス" を使う

$resource サービスを使った実装だと、Web API 側のエンドポイント URL を指定して "リソースクラス" を生成していたはずだ。

var bookClass = $resource('/api/books/:id', { id: '@Id' });

この "リソースクラス" を new でインスタンス化、そのときのコンストラクタ引数に "素の JavaScript オブジェクト" を渡すとよいのだ。

var newBook = new bookClass($scope.newForm.book);

こうすると、コンストラクタ引数に渡した JavaScript のメンバを複製した、加えて $save() などのメソッドを備えた "リソースオブジェクト" が返るのだ。

$save() メソッドが備わっているので、はい、$save() メソッドを呼べば OK だ。

newBook.$save();

これでサーバー側には次のような XHR 要求が送られる。

POST /api/books

...

{"title":"(title)"}

仕上げとして、普通は、エンティティの一覧を下記のとおりクライアント側に取得済みだと思うので、

$scope.books = bookClass.query();

この一覧は JavaScript の配列になっているので、push() メソッドで要素追加すればよい。

$scope.books.push(newBook);

さらにはこの一覧はビューにバインドしているのが大抵だと思うが、もちろん、push した段階で、ビューも更新される。

サーバー側実装に注意

ところで、サーバー側実装については、一点、注意が必要である。

一般的にこれまでの例で示したようなコードでは、Book 型の id メンバの値は、サーバー側の向こうにあるデータベースシステムによって、データ追加のたびに自動で発番する形態となっていることだろう。

それを踏まえつつ、さて、Visual Studio で Web API コントローラーのひな形を作ると、エンティティの新規追加用のメソッドは以下のとおり、戻り値が void になっている。

public void Post([FormBody]Book value){

  ...

}

しかしこのコードだと、クライアント側に、自動発番された id 値が伝わらないのだ（当たり前だが、戻り値が "void" なので）。

これだと先のクライアント側のコードで newBook.$save() しても、変数 newBook が指す id プロパティは undefined なままである。
そののちにこのオブジェクトに対し変更や削除を行っても、対象オブジェクトが不明のままエラーとなること必至だ。

なので、サーバー側実装では戻り値を void ではなく、id 値が附番されたあとのオブジェクトを返すようにするとよい。

Entity Framework を使った例だとこんな感じだろうか。

public Book Post([FormBody]Book value){

  using(var db = new BookDb()){

    var newBook = new Book {

      title = value.title

    };

    db.Books.Add(newBook);

    db.SaveChanges(); // ここで newBook.id にDB側が発番したID値が

                      // 書き戻される

    return newBook;

  }

}

こうしておけば、クライアント側で新規作成したリソースオブジェクトを $save() したときに、id プロパティ値が設定されるようになる。


以上で $resource サービスと ASP.NET WebAPI の組み合わせにおけるエンティティの CRUD 処理がスマートに実装できることだろう。