コンテンツ
どのフレームワークを使用するかを尋ねてください。恐らく不機嫌そうな老婆の瞬間があり、すべてのフレームワークが互いに同じくらい悪いと言います。すべてが悪いと言っているわけではありませんが、PHPには想像を絶するほど多数のフレームワークがあり（通常はN + 1として引用されます。ここで、Nは世界のPHP開発者の数です）、おそらくすべてが理にかなっています。それらを発明した人に。
フレームワークを選択する方が、構築しようとしているものに関係なく、1つのフレームワークだけを使用するよりもおそらく優れています。これは、フレームワークが「最良」のフレームワークであるためです（「最良」の基準を問わず）。このフレームワーク製品の選択は、プロジェクトのニーズを満たすものを選択できることを意味し、文書化されることもあります。どのプラットフォームのフレームワークも、構造、再利用可能なモジュール、およびライブラリを提供するために実際に存在し、通常、同じ機能を何度も構築することに伴う退屈で反復的なタスクをすべて回避します。たとえば、CMSを構築する場合、フォームフィールドを処理して検証する必要があります。自分のデバイスに任せておくと、重要なことを見逃してしまう可能性があります。むしろ、各プロジェクトの要素である 異なる、毎回同じものではなく！
フルスタックフレームワーク
Zend Frameworkなどのフルスタックフレームワークは、アーキテクチャの経験があまりない開発者にとっては、開始するのに適した場所です。それは、新しいアプリケーションを掛けるための優れた構造を提供し、その周りには優れた「エコシステム」があります。たくさんの本、チュートリアル、そしていくつかの合理的なドキュメントもあります。多くの人が管理する大規模なアプリケーションを構築しようとしている場合は、非常に多くの構造を決定し、よく知られ、理解されているため、人気のある包括的なフレームワークが適しています。
分離を助けるための構造を持つことは常に良いことです。私のキャリアの早い段階で私はいくつかと一緒に働いた 非常に ジュニア開発者は、当時比較的新しいMVC（Model View Controller）パターンを彼らに教えようとしました。ビューレイヤーでSmartyを使用することを決定しました。デザイナーがテンプレートをより簡単に操作できるようにするためと、誰かが私のデスクに来て「SmartyでXを実行するにはどうすればよいですか？」と言ったときのためです。 「ビューでXを実行しないでください！」と言えます。 （10回のうち9回が答えでした）。フレームワークがあると、アプリケーションの他の部分で同じ分離を見つけるのに役立ちます。それらの多くは、Smartyや私の新しいお気に入りのTwigなどのテンプレートレイヤーに対する統合をサポートしているため、選択したフレームワークに関係なく、これらのツールを持ち運ぶことができます。
負担を軽くします
Zend Frameworkよりも軽いフレームワークがたくさんあります。たとえば、私はCodeIgniterをかなり使用しています。 Zend Frameworkと同じくらい包括的で堅牢ですか？いいえ、そうではありません。ただし、アプリケーションを迅速に構築できるようにするためのヘルパーフレームワークとしては、便利です。一般に、「ヘルパー」機能が少ないフレームワークは、要素がどのように連携するかがはるかに明確であるため、簡単に回避できます。なじみのないフレームワーク（私にとっては、それがほとんどすべてです）では、操作とデバッグを困難にするのは自動魔法のビットです。
「新しいフレームワークで失われた」というその感覚は避けられず、まったくイライラします。経験豊富な開発者でさえ、何がどのように機能するかを知らないと、初心者のように感じます。本当に運が悪ければ、IRCチャンネルがあなたもバカだと教えてくれるフレームワークを選んだでしょう！多くの人が新しいフレームワークを使用したり、最初にフレームワークを採用したりするのを思いとどまらせるのは、この非常にネガティブな初期の経験であり、その初期のハードルを超えて新しいユーザーを支援するのに役立つフレームワークはほとんどありません。
PHPには、私が通常使用する方法では実際にはフレームワークではないフレームワークもいくつかあります。素敵なコンポーネントフレームワークがいくつかあります。 Zeta Components（以前のeZ Components）やSymfony Components（彼らのサイトを見たことがありますか？彼らは最高のアートワークの賞を受賞しています！）など、自由に使用でき、一緒にうまく機能するように設計されたライブラリのコレクション。もちろん、これらの中で最もよく理解されているのは、PHP独自のPEARおよびPECL製品です。この勇敢な新しいフレームワークの世界では、どういうわけかこれらは忘れられています。
マイクロフレームワーク
マイクロフレームワークはPHPの新しいトレンドです。これらは、物事をより迅速に接着するのに役立つ超軽量の製品です。良い例はSlimです。これは非常に高速で使いやすく、RESTfulな概念を理解しています。これは、URLパターンである「ルート」の概念に基づいています。ルートを登録し、そのURLが要求されたときに呼び出されるコールバックを提供します。
ほとんどのPHP開発者は、フレームワークを採用してそれに固執します。あるいは、仕事でフレームワークを使用し、趣味やオープンソースプロジェクトに別のフレームワークを使用する場合があります。使用する「最良の」フレームワークについてはほとんどコンセンサスがないため、誰もが知っていることに固執するだけで、その結果、膨大な数のフレームワークが並行して開発されます。私は選択するのが大好きですが、それらはすべて互いに同じくらい悪いと言いましたか？
Zend Frameworkを知っている場合は、ZendFramework開発者として自分自身を説明することになります。別のフレームワークを理解する機会が得られるまで、別のフレームワークでの記述に慣れることはできません。また、PHP関数を頻繁に使用しない場合は、そのための生のPHP関数の多くを覚えていない可能性があります。私たちがフレームワーク固有の開発者になり、抽象化レイヤーの上でのみ作業するというこの考えは、PHPにとって少し奇妙です。結局のところ、これは「Webの問題を解決する」という言葉です。これはCで記述されており、それ自体が高速で軽量な言語です...大規模なフレームワークブートストラッププロセスが実行されるのを待たないことを条件とします。この文脈から、私たちがFunkatronと呼ぶ男性によって書かれたMicroPHPマニフェストが登場しました（彼の名前は実際にはEd Finklerですが）。これは、相互運用可能な小さなモジュールを多数作成しても問題がないこと、大きいほど良くないこと、そして実際には、PHPで記述されていても、Javaには寿命が短すぎることを示す一連のステートメントです。
