サービス指向とリソース指向API

ActiveResourceから広がった妄想をメモ。僕自身はRailsに手を出す予定はしばらくは無いです(凄腕のひとたちが参入しきってるから)。

サービス指向API

特定のレイヤとかパッケージのサービスを公開する一番フツーのやり方。パッケージを代表するFacadeを公開し、その操作としてサービスを提供する。
たとえば、、

ビデオをレンタルする。
VideoManager.rental(videoID, member)
ビデオを返却する
VideoManager.returnVideo(rentalID)

とか。
オブジェクト指向プログラムっぽくはないけど、一般的。多分パッケージ内部ではごちゃごちゃやってる。
弱点として、意外にサービスのAPIって利用者側の要求に引っ張られるなーという点がある。

リソース指向API

複数のリソース(というかオブジェクト)を公開し、それに対するCRUDでサービスを表現する。

レンタルするということは、イベント「Rental」を作成すること。
(単に作成するわけじゃなくて、その瞬間にビジネスロジックが走る)
Rental rental = rentalFactory.create(videoID,memberID);
返却するということは、イベント「Replacement」を作成すること
Replacement replacement = replacementFactory.create(rental.getID());
(別解)返却するということは、rentalの状態をアップデートすること
Rantal rental = rentalRepo.find(...)
rental.setState(RETURNED)

公開しているリソース(というかオブジェクト)はDomainオブジェクトとかEntityオブジェクトとはイコールじゃないイメージ。状態付きのFacadeみたいな感じ。ビジネスロジックはCRUDに連動する形で内部で走る。
ここまで書いてみて、一見かっこいいんだけど、そもそもメリットあるかどうかわかってない。。。練り不足。
ぱっと思いつく反論は、

• 個々のリソースではなくて、複数のEntityを結合したような複雑なビューを一気に取得するサービスとかはどうするの

とか。
多分そういうビューを表現するリソース(というかオブジェクト)を定義するのかなー。