自社案件のライブラリ化にようやく目処が付いた。20日弱かかった。
開発時にちょっと強引な環境構築をしたので、そのメモ。他の人が読んでも参考になるところはほとんどないと思うが、実開発利用の一例として。
今回作ったのは、ドメインモデル。ライブラリを作るのにEthnaが提供してるbackend機構やらUnitTest環境が便利だったので、活用させてもらった。各種ビジネスロジックはAppManagerをextendsして実装。
Ethna自体は、今どきのPHPフレームワークほど高機能では無いが、シンプルでわかりやすく、取り回し(好きなような使いかた)がしやすい印象。いかにもPHPといったかんじ。正直、かっちりしたフレームワークをちゃんと使いたいのであれば、PHPじゃないほうがよっぽど書きやすいし、今回のライブラリ化でそれを痛感した(PHP4/5(自社環境的にそうなる)で、自社要件の範囲内でちゃんと機能するObject#equalsをゴリゴリ書くとか、泣きそうだった)。が、特にうちのような業務要件においては、思い付いたことをさくっと試してみたいことが多いし、そういうのにPHPは向いていると思う。
一方、本来であれば、ビジネスロジックの部分は独立実装しておいた方がよかった。フレームワーク依存してしまうので。ここは追々利用状況をみながら依存性排除していこう。インタフェースを合わせておけば問題ないし。
最終的なライブラリは、以前PHP勉強会でご紹介いただいたsakamotoさん作成のPEAR_PackageProjectorを使わせていただき、PEARパッケージング。問題なく使えました。
で、このパッケージは自社用共通ライブラリ置場(PEAR置場含む)を定義して(今回は/usr/local/lib/pear/foo)、そこに展開。
パッケージ内に各種テストケースをEthna_UnitTestCaseをextendsする形で作成。
開発時の動作確認はドメインモデル開発用のプロジェクトhogeをadd-projectし、app以下にPEAR以下の開発中ライブラリをsymlink。これで、PEAR以下で開発しながら、そのUnitTestをhoge以下app/hoge_UnitTestManager.phpで実行。できたものはPackageProjectorで逐次固めていく。動作確認用のプロジェクトfugaをadd-projectしておいて、そこでライブラリ利用コードを逐次書く。
全体の構成はこんなかんじ。これで、ライブラリを作りつつ、テストもやりつつ、利用プログラムを書きつつ、のサイクルが手元で全部回せる。
/usr/local/webapps/hoge .. ライブラリテスト用プロジェクト
|- /app/foo -> /usr/local/lib/pear/foo .. unittest用にhoge以下に持ってきておく
|- /www/unittest.php <- /var/www/unittest.php .. テスト確認用にDocumentRootからsymlink
/usr/local/webapps/fuga .. ライブラリ利用プロジェクト
上記構成で、/usr/local/lib/pear/foo 以下のライブラリを更新しつつ、unittest.phpで逐次動作確認し、うまくいっているようならPEARパッケージングしたり、プロジェクトを想定したfugaからの利用を試行してみたり、というかんじ。
うまくビジネスロジックをライブラリに閉じ込めることができたので、今後の自社サイトはこれを利用してEthnaのプロジェクト単位で作っていけるようになるはず。業務ロジック/ルールを意識することなく、Actionからライブラリ上の各種Managerをコールするだけで済めば、もっといろんなサイトがごりごりぼこぼこ作れるとおもう。
業務分析をいろいろやったので、その経緯は、また今度書く。
関連していそうなエントリ:
最近のコメント