BEAR.Sunday Meetup #0に参加してきました
PHPのフレームワーク、BEAR.SundayのMeetUPに参加してきました。
Ray.Di Ray.Aopことはじめ
Bear.Sundayのコア部分の解説
- 「問題の解決に実装でなく設計で挑もうとしている」
- さまざまな思想が詰まったフレームワーク
- RayとBEAR.Resorceの二つの柱
- RayはGoogle Guiceがヒント
- RAY,DIはAura.Diベース
- とてもクリーン。全て外部から注入され、固定クラスが無い
- Doctrin/Common.Annotationsによるアノテーション実装
- Symfonyライクな書き方も可能
- アノテーションでインジェクションを指定する場合
- モジュールで設定を定義
- 通常のコンテナで取得
- インターフェースを必要とするところに一度に注入できる
- モジュールは特定の関心領域についての設定や構成を行う単位
- モジュール自身もDIによって入れ替えられる。
- ふるまいはAOPで変更する
- Ray.AOP
- Ray.DIはオブジェクト生成のためのフレームワーク、Ray.AOPはオブジェクト利用のためのフレームワーク
- 生成と利用の分離
- 生成レベルでキャッシュできるので、コストが非常に低くなる
ここでBEARの開発者によるオブジェクトグラフの説明。
僕と熊の三年間
エキサイト(!)でBearフレームワークを全面的に採用したケースについて
リソース指向のデータ転送
開発者によるBear.Sundayの開発
Frameworkとは何か?
- 設計思想である
- 設計思想とはシステムに秩序をもたらす価値観
- どのような価値観をもって問題を解くか?
オブジェクト指向とは何か?
MVC
- MVCについては捕らえ方が人によってばらばら
- パターンは価値観の表現が無意味
- 「MVCはアプリケーションのパターンではなく関心の分離のパターンである」
- 典型的なMVCはtellでなくASK
- ROAの条件
- アドレス可能性
- ステートレス性
- 接続性
- 統一インターフェース
BEAR Sundayの場合
- リクエストに対してリソースの表現が返る
- 関心事に応じて複雑になる
- これならぱtell
- アクセスはURIと挙動で
- 戻り値は常にリソースオブジェクト
- モデルをオブジェクトにしなければもっとわかりやすくなるのではないか?
- 世界最大のスケーラブルモデルであるwebの構造をまねする
- 状態をViewに変更するのがリソースレンダラ
- リソースごとにテンプレートエンジンを注入
- リソースは関係性を元にリンクをもち、関係性を隠蔽している
- リソースが関係性でつながっている(リソースグラフ)
- リソースがURIで表記されることで抽象度を上げ、依存性をなくす
- Because Everything is A Resorce
「問題の見方。物事をどう見るのかが大事」