- summary BEARについて
- labels Manual,Phase-Design
http://www.bear-project.net/blog/wp-content/uploads/2011/07/bear_prv.gif
BEARはリソース指向のPHP Webアプリケーションフレームワークです。
* *ページ* - リソースリクエストとリソース状態のビューへのプッシュ * *リソース* - インターフェイスとURIを持った情報 * *ビュー* - リソースの表現
リソースをHTML表示する単純な例です。
# ブラウザからリクエストされた*ページ*が*リソース* をreadします。 # 取得したリソースを*ビュー* にプッシュ(set)してHTML表示します。
一般に、MVCフレームワークがモデルをオブジェクトとして扱うのに対してBEARではリソースとして扱います。
オブジェクトとリソースの最大の違いはリソースそれ自身がメソッドを持たない事です。 リソースはメソッドを持たない変わりにリソースリクエストに対する統一されたインターフェイスを持つ事ができます。
HTMLページとはリソースをHTML化したものと考えてみましょう。例えば、ブログの記事のページとは*ブログ記事リソース* を視覚化のためHTML表現にしたものとリソース中心に考えます。１つのページは単数または複数のリソースを持ちます。記事ページには記事リソースの他にコメントリソースや、トラックバックリソースもあるでしょう。それらのリソースは互いにリンクされています。それぞれのリソースは表現のために各々がビューテンプレートを持つ事ができますが、リンクされた状態のリソースにもテンプレートを適用する事ができます。リンクはカプセル化され利用はリンク先をたどるだけです、aタグでhrefの中身を知る事なしにリンクをクリックするようなものです。
特徴としてBEARで作成するページは、リソース中心のフラット構造になりデータソース(DB)/モデル/ビューなど各レイヤーでの不整合（オブジェクトリレーショナル・インピーダンスミスマッチ）が起こりにくいものとなります。
ページからビューへの”リソースPUSH"だけでなく、ビューからリソースへの"リソースPULL"も可能です。ページからビューへのセットもイーガー（即時）セットだけでなくレイジー（遅延）セットも可能です。リソースはページ以外のクライアントを持つことができます。ソケットサービスやCLI、コメット/MQ用ソケットサービス、他のwebサービスからでもリソースは利用できます。それらのはすべてリソースが「統一されたインターフェイス」しか持たないRESTの特徴によるものです。モデル（リソース）の独立性、再利用性はBEARの大きな特徴です。
作成したリソースをHTML以外(XML/JSONなど)のフォーマット指定して出力できます。PCから見たHTML, 携帯端末からみたHTML、webサービスからアクセスされたHTML、ソケットとして提供するパケット、どれも同じ記事リソース から出力されたもので*表現のフォーマット*が変わるだけです。リソーステンプレートを用いれば、リソースの本質的値とそのHTMLはリソースの粒度で独立します。HMVCのようなレイヤードな階層構造です。
リソースはDBの他に、外部RSS/XML、ローカルのCSVなどをデータソースとすることができます。いずれの場合も共通形式の*URI* を用いリソースを指定します。*CRUDインターフェイス* 、*キャッシュ機構*、*ページグネーション* 、アスペクト指向プログラムの*アドバイス適用*, *モック使用*などの共通のリソース 操作オプションが利用できます。URIはスキーマをもち独自のデータソースアクセスロジックを用意することが可能です。既存のロジックやデータソースをURIとして統一管理できます。
モデルをデータソースとして扱うフレームワークがあります。一方、モデルはそのドメイン(領域)の責任を持った自律的なドメインモデルとして実装すべきという主張もあります。
BEARでのモデルは、リソースとしてURIスキームやリソース内部の実装に応じてデータソース、サービスレイヤー、ドメインモデルと変化します。それはモデルのあり方はフレームワークが規定するものではなくてアプリケーションが規定するものであるという考えに基づきます。たとえばトップページの「今週のお知らせリソース」は簡単なデータソースURIで十分でしょう。一方、「航空管制システム」ではAdrive Recordでは不十分でドメイン駆動設計されたドメインモデルが適しているでしょう。
モデルのあり方よりもむしろモデルと他のコンポーネントとの結合に着目し、RESTを使って接続するのがBEARの基本アーキテクチャです。
webサイトを「URLを単なるコントローラやモデル呼び出し用の引数とする一つの大きなwebアプリケーション」として考えるより、「1URLがそれぞれ独立したページリソースを表現するリソースの集合体」のように考え*ページ設計*を主体とします。フロントコントローラーではなくページコントローラーです。
リソースであるページは、多くの場合他のリソースを読み出し合成してビューにPUSHします。リソースのレイヤリングです。たとえば「ユーザーページリソース」は「ユーザーリソース」と共に「ユーザーの友達リソース」「ユーザーのプロファイルリソース」などのリソースにreadリクエストを行い得られた「ページリソース」の結果をテンプレートと合成してHTMLで表現します。
- 1URL* につき *1ページクラス* を用意し、ページクラスにページの*イベントハンドラ* を記述します。メインクラスはそのページのハンドラーをイベントに応じて呼び出しオブジェクトをページを動作させます。ページが最終的に返すhttpリソースが最終的に出力されHTMLとして表現されます。
ページではonAction, onClick()などページイベント発火したときにコールされる処理を記述します。 BEARではonで始まるイベントハンドラメソッドを記述することがプログラムの中心になります。
オブジェクトの生成、設定、依存の注入を専用で行うDIツールを用いることで、オブジェクトの生成や依存する利用オブジェクトの関係やインスタンス管理を柔軟にコントロールでき、テストや変更がより容易になります。
BEARの多くのフレームワークコンポーネントがフレームワークソースを触る事なしに自作のコンポーネントと差し替え可能です。またオブジェクトの遅延生成やインジェクトキャッシュも可能です。これはすべてクラスが統一されたインターフェイス（コンストラクタと設定、インジェクト）を持ち、DIツールが全てのサービスオブジェクトをグローバルレジストリでシングルトン管理するサービスロケーターにより実現されています。
* PHP5.2+
* 基本ライブラリはPEAR
* フルスタックでなくプラガブル
* ViewはデフォルトでSmarty
* UAスニッフィング（携帯/モバイル端末他/複数ブラウザ対応）
* エンコードは携帯含めて全てUTF-8
* 二重投稿、CSRF対策などのセキュリティ機構
* ログ、キャッシュ(File/APC/Memcache)、イメージ(GD/iMagick/Cairo)
* エラーハンドラ、デバックツール
* オンラインエディター
* コマンドラインインターフェイス
* オートローダー標準
* PEAR/Zendスタイルコーディング
* ソケットサービス
コンセプト、より専門的な設計指針、影響を受けたフレームワーク、ライブラリやその他情報ソースについては[software_design]をご覧ください。