- summary リソースサンプル
アプリケーションリソースのユーザーリソースサンプルコードです。 このユーザーリソースでは、CRUD操作全てに対応していて、プロフィールリソースへのリンクも持ちます。リンクはリソース内でカプセル化されているのでリソースクライアントからはユーザーリソースとプロフィールリソースの関係を知る事なしに、リンクで２つのリソースが接続されています。
DBオブジェクトはURIとCRUDに基づいて親クラス`App_Ro.php`でインジェクトされます。ユーザーリソースのファイルであるApp/ro/User.phpではDBオブジェクトを取得するコードがありません。ここではDBアクセスにPEAR::MDB2を用いてますが、本来Roリソースは特定のデータベースオブジェクトに依存していません。
URIとメソッドに基づいてDBの接続先がとクエリーツールがインジェクトされています。DBのSQL操作を行うBEAR_Queryクエリーツールを使ったSELECTでは、外部からLIMITやDB Pagerの適用といった操作が行えます。クエリーを行うイベントハンドラメソッド(onRead等）では、DBの接続やテーブルの指定，ページャーオプションの指定等は行われていない事に注目してください。それらは全て対応した設定($config)で生成されたBEAR_Queryツールが行います。
またそのBEAR_Queryも、同じインターフェイスを実装した別オブジェクトにインジェクトができます。
ユーザーリソースはプロファイルリソース、フォローリソース(to, from)とリンクしています。ユーザーリソースを取得したページ内のクライアントはその中身を知らずに他のリソースの情報が取得できます。webのリンクの仕組みと同じです。
ページ内クライアントコード
複数のリンクもかけます
そこからのリンクは最後のリソースに対して行われます
通常のSELECT文がクライアントのコード変更なしでDBページャークエリーに変更できます。LIMITの指定もできます。
onUpdateではAOPを使ったトランザクションが適用されています。トランザクションはphpdoc部分に以下のように記述します。
画面一枚あたりのアイテム数等をリソースに依存させるのではなく、ページから伝えたいときがあります。その場合はページからのオプションreadの引数の`$params['option']`を以下のようにROで取得してクエリーツールを生成します。
返り値はoオブジェクトに変換されページに帰ります。ユーザー一覧$userを連想配列でreturnすると以下のようなRoオブジェクトとなりページに渡されます。
* コード 200 (OK) * ヘッダー なし * ボディ $user
UpdateとDeleteに@requiedアノテーションが指定されていて、アクセスするキーに`id`が無いとエラーリソースオブジェクト(Ro)がページに帰ります。
URIとCRUDメソッドに基づいてデータベース接続先を決定し接続したDBオブジェクトをインジェクトします。スケールアウトの時にクライアントコードを書きなす事なくDB接続先が変えられます。セレクトのときはDBページャー可能なクエリーツールを準備、更新系メソッドの時はSQL生成のモジュールを読み込んでいます。可能な限りの準備を集中して行い、それを元に各々のインジェクターでクエリーツールをインジェクトしているのでイベントハンドラ内のDB操作は極小化されていますが、SQL操作の自由は保持しています。