そもそも、特別な必要がないとしても、私はパッチを適用してひきつらせるものの非常に大ファンだと言います。 そして最近、サーバー上のXCache統計を考慮して、さまざまなフレームワークのopcacheファイルに費やすメモリ量を最適化できると考えました。 これを行うのは簡単です-1つだけを使用してすべてを書き換えるには、そのファイルはすべてのサイトに共通であり、私は約20を持っていますが、ほとんどの場合、それらは非常に簡単であり、それらを書き換えるのに特別な困難はありませんでした。 そして、フレームワークを探し始めました。フレームワークは、理想的には、開発を単純化すると同時に簡単かつ迅速にするのに十分な機能を備えています。 ここに私が好きなものとそれらについての私の考えがあります。
ファルコン
何よりも興味深いのは、Cで記述され、PHP用のモジュールとしてコンパイルされているためです。 ベンチマークから判断すると、他のものよりもはるかに高速に動作し（平均よりも3倍速い）、同時にかなり馴染みのあるMVC構造を観察します。 また、PhalconはDependency Injectionを使用し、独自のDIコンテナーを提供することも非常に嬉しく思いますが、チュートリアルから判断すると、静的メソッドを含むクラスが直接使用されることがよくあります。 ちなみに、タンバリンと一緒に踊ることなく、モジュールが初めてコンパイルされて獲得したと言わなければなりません。 少し詳しく見てみると、多くの欠陥が見え始めました。まず、Cの開発に役立つほどCを熟知しているPHPプログラマーがあまりいないため、PhalconはPHPの開発者よりもゆっくりと開発されます。 第二に、SQLを置き換えるPHQL（Phalcon Query Language）など、多くの松葉杖を発明しました。 その結果、未知の未来を持つかなり大胆なプロジェクトができました。
ピクシー
最近私はそれについて聞いた、Phil Sturgeon（PyroCMS開発者でPHP-FIGのメンバー）のツイートで言及されていたが、最初は単なる冗談だと思った。 真剣に、私は、PHPプログラマーが笑わずに最後までメインページのイントロを聞くことができないと信じています。 PHPixieの哲学は、フレームワークが小さな妖精のように素早く簡単であるべきだということです。これは、開発者が「単純なことは単純であるべきで、困難なことは可能である」のような有名なパイニストのアプローチで達成しようとしているものです。 つまり、PHPixieのコンポーネントは、開発サイトのルーチンタスクの90％に最も簡単かつ迅速に対処できるように記述されており、残りの10％のより複雑なタスクは開発者自身が解決することになっており、フレームワーク自体に含める必要はありません。 私のサイトはPHPixieで発生しなかったものを使用していなかったと言わざるを得ません。また、Service Locatorを使用する傾向がありますが、Dependency Injectionでさえ非常に優れています。 DIコンテナの他の実装とは異なり、クラスを拡張することで新しい要素が追加されます。クラスは柔軟性が低くなりますが、手続きコードを回避し、IDEのコンテナ要素のクラスを認識しながら、より透明になります。 マイナスの点については、真剣に考えるのは非常に困難であり、オフィスの従業員にフレームワーク上で妖精やポニーで何かを書くよう説得することはできません。
無脂肪
フレームワーク全体を1つのファイルに！ すぐに大きなプラス：ディスクからの1つのファイルは、多くのファイルよりも速くロードされ、このファイルのサイズは約50キロバイトです。 確かに、このファイル全体はフレームワーク全体からはほど遠いですが、その主要部分のみ、つまり、たとえばデータベースにアクセスする必要がある場合はクラスをロードする必要がありますさらに、同じXCacheはPHPコードをキャッシュしますこのアプローチから得られる利益は、もしあれば、非常に小さいでしょう。 多くのライブラリがフレームワークとともに提供されます。これは、Composerを使用せず、まったく使用する必要がない場合に便利です。 また、ORMがテーブル間のリレーションをサポートしていないことも非常に驚くべきことでした。 これは実際に私がレビューした唯一のフレームワークで、本当にがっかりしました。
Silex 、 スリムおよびマイクロフレーム。
これら2つについて多くのことが知られています。 どちらも開発用の完全なスタックを提供しないため、すべては、どのライブラリーをねじ込むかとその方法に依存します。 マイクロフレームの柔軟性はこれに由来しますが、一方で、結果として各プログラマーが独自のシステムを持っているため、コミュニティとサポートを見つけることがより困難になります。 さらに、フレームワークがすべて1人で書かれている場合、コードの哲学は似ているため、習得するのははるかに簡単です。 しかし、異なるスタイルとアプローチを持つ異なるライブラリから組み立てられたフランケンシュタインがある場合、それを理解することはより困難になります。 最終的に、Silexを完全なeフレームワークにしようとすると、何らかのSymfonyのコレクションにつながります。 SlimとSilexでコードを書くことは直感的で、高速で、魔法を使わないことに注意してください。
リチウム
開発者によると、たとえば、SQLデータベースとNoSQLデータベース用の単一のAPI、および分散フィルターシステムなど、もう少しイノベーションがあります。 このフレームワークは、CakePHPの元開発者によって作成されたもので、モデルを使用する場合など、非常に目立っています。 フィルタを使用すると、クラスメソッドの呼び出しを実際にインターセプトし、そのパラメータと結果をオンザフライで変更できます。 柔軟性がありますが、最終的には、Wordpressでプラグインが機能する方法に似たパスタコードを取得できます。 また、このような革新的なフレームワークが静的メソッドを永続的に使用していることも驚くべきことです。 単純なアーキテクチャは優れています。つまり、単純なサイトを作成する場合、記述するコードの量はSilexを使用する場合とそれほど変わりません。 原則として、これは過去にCakePHPで作業したことがあるが、新しいことを試してみたい人に非常に適しています。
最後にどれを選びましたか？ 最終的に、私の選択はSilexとPHPixieの間でした（はい、妖精を恐れていませんでした）。その結果、私はまだ両方を使用しました。 ほとんどのサイトはSilexに翻訳され、Kohanaで書かれたサイトはPHPixieに移植されました。PHPixieのインターフェースは、特にORMの実装に似ています。 これを行うことで、XCacheが消費するメモリ量を約6倍削減し、ページ生成を高速化し、途中でリファクタリングすることもできました。 一般に、PHPは1000のフレームワークの国であるため、誰もが好みに合ったものを見つけることができると思います。