FuelPHPの使いどころ

結論からいうと、Webアプリケーションの開発にFuelPHPを採用する最大の理由は「よくあるレンタルサーバーを流用したい」という点に尽きるように思います。

フレームワークそのものの開発コミュニティの活性度からいうとRailsを採用したいケースは多々あると思いますが、Railsを利用するためにはrubyのホスティング環境を用意する必要があります。

Webサービスは作った瞬間から保守が始まるので、人員体制も含めてRailsの下層部分の保守に見通しが立たないと選択しづらいケースがあります。

FuelPHPはベース機能がRailsに比較的近い構成になっていて、カオスにならない程度の構造化はしやすいことと、一度環境をセットアップすればアプリケーションサーバ類の運用を考えなくて良い点で気楽に使えるフレームワークとしてはバランスが良い印象です。

参考書籍もある

PHPのフレームワークは、かつて人気があったものの最新版は下火になっていたり、新たに流行って来ているもののドキュメント類が乏しかったりと、選択が難しい面があります。

FuelPHPは現時点の最新安定版に対応する参考書籍が存在しているので、PHPエンジニアであればそれなりに入っていきやすいだろう、という点も保守の観点でプラスではあります。

参考書籍については2015年1月時点では2種類出回っていますが、そのうち『改訂 FuelPHP入門』の方がベターだと思います。一つひとつの項目について相対的に深く掘り下げられており、リファレンスとしてまずまず機能的です。

ただ、改訂版の割には誤字が多い点は割引材料ではあります。

データベースのテーブルが増えてモデルが複雑になってくるとコードが読みづらくなる懸念はあります。

たとえばORMの機能で複数テーブルをクラス構造のように利用できますが、これが3層以上の構成になってくるとarrayの記述が乱立してきて非常に読みづらくなってきたりします。

拡張性を考慮した構造にはなっているものの、PHPの基礎的な部分の影響でじっさいにはあまり拡張はしたくない、という見通しです。

PHPとMySQLを提供しているレンタルサーバーは多いと思うので、その点のハードルは少ないはずです。

PHPはあまりに古いバージョンの環境はサポートしていないので、詳細なバージョンについてはFuelPHPのサイトで確認してください。

どちらかというと、本番環境のポイントとしては「PHPのCLI（コマンドラインインターフェース）を使える必要がある」という制約の方が課題になりそうです。

標準的な操作にしたがうと、データベースの構築などにoilコマンドが必要になります。

CLIがある場合とない場合の本番環境の運用方式については、下記の比較を参照してください。

CLIなしの場合は、より深くFuelPHPの挙動を理解していないとトラブルが生じる可能性が高いと考えられます。

oilコマンドを使えるため、開発環境で作成したmigrationを使って本番環境を構築できる
PHPアプリは、gitでデプロイできる。FuelPHPの.gitignoreデフォルト設定によりライブラリ類が管理対象から除外されるので注意。ただし前提となるライブラリ類はPHP CLIを用いてphp composer.phar updateコマンドでインストールする

oilコマンドを使えない。データベースアプリを作る場合には、開発環境で作成したデータベースからスキーマとデータをバックアップ＆リストアで本番環境に移設する必要がある（標準的なMySQLの移行手順）
DBさえ構築できてしまえば、PHPアプリはファイルのデッドコピーで動かせるはず。
コード類は、プロジェクトディレクトリを丸ごと（アプリのコード＋FuelPHPのコアコード＋依存ライブラリ群）コピーする。gitだと、デフォルトの挙動ではアプリのコードしか転送できず、composerが使えない環境では構築作業が完結しない
コマンドラインから起動する自作oil refineタスクを作っても使えない

⁋ 2015/02/05↻ 2024/12/18