こんにちは、かつコーチです。
久しぶりにPHPネタです。
前回は、、、素のPHPで簡易的なルーティングとコントローラの仕組みを自作してみました。
たった数ページの機能を作るだけでも、URLの振り分けやファイルの読み込み管理など、地味な手間がたくさん発生することを実感してもらえたと思います。
今回はPHP基礎編の最終回として、「なぜフレームワークを使うのか」を整理していきます。
フレームワークとは何か
ライブラリとの違い
フレームワークとは、アプリケーション開発の「土台」や「骨組み」をあらかじめ用意してくれる仕組みのことです。
よく比較される言葉に「ライブラリ」がありますが、両者には明確な違いがあります。
| ライブラリ | フレームワーク | |
|---|---|---|
| 主導権 | 自分のコードが主役で、必要な機能だけを呼び出す | フレームワークが主役で、決められた作法に沿ってコードを書く |
| イメージ | 工具箱から必要な道具を選んで使う | あらかじめ作られた家の骨組みに、自分の部屋を作り込んでいく |
| 例 | 日付操作ライブラリ、画像処理ライブラリなど | Laravel、Symfonyなど |
「自分が呼び出すか」「相手に呼び出されるか」という主導権の違いが、ライブラリとフレームワークの本質的な違いです。
フレームワークが用意してくれるもの
前回、私たちは自力でミニフレームワークを作ってみましたが、実際のフレームワークはもっと多くのことを最初から用意してくれています。
- URLとControllerを対応づけるルーティング機能
- クラスファイルを自動で読み込むオートローディング機能
- データベース操作を簡単にするORM（Laravelでは「Eloquent」）
- ログイン機能や権限チェックなどの認証・認可の仕組み
- 入力値のチェックを簡潔に書けるバリデーション機能
- SQLインジェクションやXSSなど、セキュリティ対策の下地
これらを毎回イチから自作するのは、時間もかかりますし、抜け漏れによる脆弱性のリスクも高まります。
なぜ素のPHPだけで開発しないのか
このシリーズで体感してきたこと
このシリーズを通して、皆さんはすでに次のようなことを体感してきています。
- PDOでのDB接続は、素で書くとコード量が多く、ミスも起きやすい（P26〜P30）
- 複数人での開発では、コードの書き方の統一が難しい（P21〜P25のオブジェクト指向編）
- MVCの考え方自体は素のPHPでも再現できるが、ルーティングや共通処理の管理が煩雑になる（P38）
- ミニフレームワークを自作すると、requireの管理などの地味な手間が積み重なる（P39）
これらはすべて、「フレームワークがなぜ必要とされているのか」を実感するための布石でした。
私が痛感したフレームワークのありがたみ
私自身、まだフレームワークを使ったことがなかった頃、個人で受けた小さな案件をすべて素のPHPで作っていました。
最初のうちは「フレームワークなんて覚えることが多そうだし、素のPHPで十分では」と思っていたのですが、機能追加を重ねるうちに、同じようなDB接続処理やバリデーション処理をあちこちにコピーして書いていることに気づきました。
あるとき、入力チェックのルールを1箇所変更したくなったのですが、似たようなチェック処理が5つのファイルに散らばっていて、1つずつ手作業で直す羽目になりました。
修正漏れがないか確認するだけで、半日近くかかってしまったのを覚えています。
このとき初めて、「フレームワークが用意してくれている仕組みは、面倒くさがりの人間が事故を起こさないための工夫の集合体なんだ」と実感しました。
フレームワークを使うことのメリット
開発速度が上がる
ルーティングやDB接続など、土台となる部分がすでに用意されているため、自分はアプリ固有の機能実装に集中できます。
コードの書き方が統一される
フレームワークには「この処理はこう書く」という決まった作法があるため、複数人で開発しても、コードの書き方がバラバラになりにくいです。
これは、他の人が書いたコードを読むときにも、自分が書いたコードを他の人に読んでもらうときにも、大きなメリットになります。
セキュリティ対策の土台がある
SQLインジェクションやXSS（クロスサイトスクリプティング）などの代表的な脆弱性への対策が、フレームワークの標準機能としてあらかじめ組み込まれています。
すべてを自分で完璧に対策するのは非常に難しいため、実績のあるフレームワークの仕組みに乗ることは、セキュリティ面でも大きな安心材料になります。
求人・案件でも標準的に使われている
実務のPHP案件では、素のPHPよりもLaravelなどのフレームワークを使う現場が圧倒的に多いのが実情です。
フレームワークの使い方を身につけておくことは、そのまま実務で通用するスキルの習得につながります。
フレームワークにもデメリットはある
学習コストがかかる
フレームワーク独自の作法やルールを覚える必要があるため、最初のうちは「なぜこう書くのか」が分からず戸惑うことがあります。
しかし、このシリーズで素のPHPの限界を体感してきた今なら、「この機能はあの面倒な処理を肩代わりしてくれているんだな」と、納得しながら学べるはずです。
内部の動きがブラックボックスになりやすい
フレームワークが多くのことを自動でやってくれる分、内部で何が起きているかを意識しづらくなる面もあります。
ただ、これも今回のP38・P39で「MVCの考え方」や「ルーティングの仕組み」を自分の手で作ってみたことで、Laravelの内部で何が起きているかをイメージしやすい状態になっているはずです。
土台を知ったうえでフレームワークを使うのと、何も知らずに使うのとでは、理解の深さがまったく違います。
まとめ：PHP基礎編を振り返って
基礎編で学んできたこと
このPHP基礎編では、PHPとは何かという入門から始まり、変数・条件分岐・繰り返し処理といった基本文法、オブジェクト指向、PDOによるデータベース接続、そしてエラー解決の実践Tipsまで、幅広く扱ってきました。
そして今回、MVCという設計の考え方と、素のPHPで感じる限界を通じて、「なぜフレームワークが必要とされているのか」を自分の実感として理解できるところまで到達しました。
ここまで読み進めてきた皆さんは、フレームワークを「よく分からないけどとりあえず使うもの」ではなく、「自分が体感した課題を解決してくれる道具」として学べる準備が整っています。
この記事のポイント
- フレームワークは、アプリ開発の土台をあらかじめ用意してくれる仕組みである
- ライブラリとは異なり、フレームワーク側の作法に沿ってコードを書く
- ルーティング・DB操作・認証・バリデーションなど、多くの定番機能が最初から揃っている
- 学習コストはかかるが、素のPHPの限界を体感した後だからこそ、その価値を実感しやすい
- PHP基礎編を通じて、フレームワークを学ぶための土台が整った
次に読むべき記事
次はLaravel編に進みます。
現在マーケティング部門で市場調査・企画中のため、公開までもうしばらくお待ちください。
