BEAR.Sunday 2015
今年は5/31にBEAR.Sunday v1.0をリリースしました。その後は実際の運用での細かな修正や幾つかのライブラリが追加され、アプリケーションが幾つかリリースされました。年内開発終了して来年以降にリリースされるアプリケーションもあります。
BEAR.Sundayではデータベースアクセスやテンプレートエンジンといった機能を提供をするのがライブラリ、それらの機能を結びアプリケーションに制約をもたらすのがフレームワークと考えています。
フルスタックという伝統的なフレームワークの形から、ここ数年で機能が単体で使えるコンポーネント志向のフレームワークという流れが現れました。最新のPSR7対応のフレームワークはそのコンポーネントは汎用の物を使いコンポーネント間の制約だけを持ちます。HTML表現ですらオプションになっていますが、これはBEAR.Sundayも同じです。
フレームワーク
2013年に行われたイベントPHP Frameworks DayでPHPの開発者ラスマスさんへ質問がありました。
Can you tell us your opinion about a framework ?
Rasumusの答えはシンプルで明快です。
They all sucks ! （会場笑）
この質問の答えは面白いので是非聞いて欲しいのですが、まとめてあるブログ記事があります。
- Frameworks Execute The Same Code Repeatedly Without Need
- Frameworks Require Too Many Interdependent Classes
- Needlessly Complicated Solutions
- Duplicating the Web Server Functionality
これらはBEAR.Sundayでも取り組むべき問題だと考えていてDIやDIコンパイラで対処の試みがあります。DIを理想的な形、つまりブートストラップで１つのルートオブジェクトを作りそれをキャッシュしたり、設定からオブジェクトを作るのではなく、設定からファクトリーコードをコード生成しパフォーマンスや実際にどうオブジェクトが作られるか明快にしています。DIPに従い、全体のライブラリのバージョンをロックするようなグローバルなバージョンを持ちません。
メジャーバージョンアップ、つまりsemverでの後方互換性の破壊は嬉しいことではなく、後方互換性を破壊しないと機能追加が出来ない設計上の失敗 - できれば避けたいこととも考えています。
機能の追加はライブラリの仕事と考えればBEAR.Sundayのこれからは、それらをスムーズに統合できるか、パフォーマンスは十分か、トラブルシューティングの助けがどれだけできるか、ユーザーの設計上のアイデアを実現できるか、などフレームワークとしての機能の充実になるかと思います。
今年もお世話になりました。来年2016年もBEAR.Sundayを宜しくお願い致します。