2017年のPHP MVCフレームワークの状態-PHPチュートリアル-php.cn

The State of PHP MVC Frameworks in 2017

キーポイント

LaravelとSymfonyは現在、強力なコミュニティと継続的な開発の新しい機能を備えたPHP MVCフレームワークをリードしています。
マイクロサービスとコンテナベースのアーキテクチャの台頭により、MVCの役割が「関数」としてアプリケーションを構築することが変化しています。
Laravelがリードしている間、大きな雄弁なモデルと過度のサービスが複雑になり、モノリシックなアプリケーションが生じる可能性があります。
Symfonyモノリシックアプリケーションにつながる場合もありますが、リポジトリを使用することで優雅さと柔軟性を提供します。
マイクロサービスの出現は、PHPが死にかけていることを意味するものではありませんが、開発者は先にとどまり、Golangまたはnode.jsの学習を検討する必要があります。

この記事はもともとZenofcodingで公開され、著者の許可を得てここに再発行されました。

The State of PHP MVC Frameworks in 2017 簡単な質問により、約1年前に私の投稿にこのフォローアップを書くようになりました。

Q：現在の状況についてどう思いますか？（2017年2月24日）

a：「主にララヴェルとシンフェニーまでのものだと思います。PHPフレームワークに関する限り。新しいプロジェクトを開始している場合、CakePHPを使用する特別な価値はないと思います。 Zend、Codeigniter、Yiiなどこれらのフレームワークについてすでに知っている場合、またはそれらを使用する習慣がある開発者がいる場合にのみ、これらのフレームワークを使用する理由を見ることができます。実際の開発が始まるとき、ツール、プラグイン、そしてよくある質問に対する答えを見つけることができなければなりません。 LaravelとSymfonyのコミュニティと新しい「モジュール」または機能の継続的な開発により、決して後退することはありません。 Laracastsだけで（Laravelで開発していなくても）素晴らしいです。

Iron.ioやその他のSaaSプロバイダーなどのサービスとの統合、さまざまなデータソースのサポート、またはHomesteadなどのローカル開発環境など、これらのフレームワークとサポートモジュールはより将来を見据えています。

Lumenは迅速なAPI開発を補完し、Laravelは実際に今日の高速アプリケーション開発とプロトタイピングのための優れた方法です。これは、大規模なアプリケーションを構築する際に何らかの制限の対象となると言うことではありません。

ただし、全体として、MVCの効果がはるかに低いコンテナベースのアーキテクチャへの移行が見られます。それはすべて、マイクロサービス、オーケストレーション、およびアプリケーションを「関数」（つまり、AWS Lambdaおよび同様のサービス）に構築することです。たぶんそれはあなたのnode.jsとGolangのスキルを改善する時です:)」私は一般的にこの答えに満足していますが、これらのポイントのいくつかを詳しく説明し、現状を再検討することは良い考えだと思わずにはいられません。

「ゴラン」のような奇妙なトピックについて話し始める前に、一歩後退して、2017 PHP MVCフレームワークフィールドのトレンドを見てみましょう。

私たちが過去に観察した傾向は継続していると思います。ララヴェルはまだ進化していますが、他の人が遅れています。 Symfonyの人気は、おそらくSymfony 3の非常に期待されているリリースのために、わずかに上昇しました。

（「cakephp 3」や「zf2」などのより具体的な比較検索を試みましたが、これらの検索では統計的に有意な傾向は生成されませんでした）。

私は今年、Codeigniterに参加しました。それは非常に人気があったので、それは明らかでした。 CodeigniterとPHP MVCコミュニティでのその場所についての私の意見について多くの質問を受けました... 要するに、CIは実際のMVCフレームワークではないため、まだ競争していません。よく組織されたポポコレクションを除いて、それを呼び出す方法がわかりません...

マニュアルから直接引用してみましょう：

モデルが不要であるため、
codeigniterはMVCに対してかなりゆるいアプローチを取ります。余分な分離を必要としない場合、または維持モデルが望むよりも複雑であることがわかった場合、それらを無視して、コントローラーとビューを使用して最小限の方法でアプリケーションを構築できます。

フレームワークの構築に関しては、このアプローチに完全に同意しません。たぶんそれは素敵なボイラープレートであるため、Codeigniterが人気がありますが、フレームワークは特定の分野を実施するか、最終製品が何らかの「パターン化された」に包まれたスパゲッティコードの束になります。

次に、Symfony 3は、開発者のエクスペリエンス、依存関係の注入、その他多くの機能にいくつかの改善をもたらします。多くのPHPカウンターパートと同様に、マイクロフレームワークを提供するようになりました。対照的に、ZF3は、PHP7（最終的に）のサポートや独自のマイクロフレームワークなど、さまざまな改善を提供しますが、マニュアルが言っているように：

Zend Framework 2 MVCユーザーの場合、違いは微妙です...

彼らが多くの違いがあると言っていることを本当に願っています、いくつかの主要な建築の改善、そしてあなたが現代の方法で物事を開発するのに役立ついくつかの素晴らしい新しいモジュールがあります。残念ながら、ほとんどの場合、ZF3はまだZF2と非常に似ています。

長いストーリーショート

これが私が今日のPHPフレームワークの世界を見る方法です：

SymfonyまたはLaravel
その他

ララヴェルがショーを盗むことは間違いありません。利用可能な情報、ララキャスト、グローバル開発者の才能、シンプルなスキーマ実装、統合されたテストツールセット、雄弁な形でのアクティビティレコードの実装、ルーメンの軽量バージョン、ホームステッドを使用したローカル開発（Vagrant）は、このフレームワークがニュービーと両方のために際立っています経験豊富な開発者。

しかし、雄弁なモデルは乱雑になり、非常に大きくなり、潜在的に多くのLaravelサービスを作成する可能性があります（マイクロサービスと混同しないでください）。したがって、モノマーの用途が生まれました。

アクティブなレコードモードに慣れておらず、リポジトリの特別な柔軟性が必要な場合、またはあまりにも多くの匿名関数が表示されない場合は、Symfonyの教義を使用してください。 Symfonyはモノリシックアプリケーションへの道だと思いますか？ある程度、はい。しかし、それはおそらく最もエレガントなものです。

全体として、昨年と比較して劇的な変化とは言いません。それでも、より大きな観点から問題を検討する必要があります。適切に設計されたアプリケーションは、MVCだけではありません。これらはすべてMVCスタックに実装できますが、モノリシックアプリケーションを避けるために特別な注意が必要です。

マイクロサービスの出現

マイクロサービスの台頭と、Golangまたはノードのスキルを向上させる必要性について言及しました。実際、PHP MVCの記事でさえ、マイクロサービス指向のアーキテクチャ（MOA）への明らかなシフトに言及しないのは愚かです。

これらの2つの概念は相互に排他的ではありませんが、交差する哲学ではあるが異なるものを表しているため、2つの間に類似点を見つけようとする理由はありません。

たとえば、

MVCアプリケーションを1つの容器に入れ、MySQLを別の容器に入れてから一緒にリンクすることは、必ずしも適切なMOAを表すわけではありません。これは確かにより良いアプローチです。実際、MAMP、XAMPP、またはアプリケーションを提供するためにローカルマシンを取得するために必要な他の乱雑なものをインストールしようとするよりもはるかに優れています。

さらに、さまざまなプラットフォーム（開発者）でローカル環境を簡単に実行したり、場合によってはポリシーを展開したりするなど、いくつかの問題を解決できますが、MVCモノリシックアプリケーションはアプリケーションレイヤー/コンテナにまだ存在します。

モノマーアプリケーションの破壊

この種の「破壊」は、マイクロサービスが達成したいものです。 MVCは、懸念を分離する信頼できる方法を提供することにより、コード構造と組織の問題を解決しますが、コンテナ/サービス/MOAはこの概念をさらに拡張します。

モデルからビューを分離するだけでなく、アプリケーションの各「ブロック」または論理単位を独自の責任を適切に処理するように設計された別のサービスに分離します。

MVCアプリケーションに「検索」コントローラー、操作、および関連モデルメソッドがある場合、すでにモノリシックアプリケーションの例があります。

代わりに、MOAメソッドを使用して、各処理ユニットに1つのサービスを提供します。たとえば、

ルーティングサービス

リクエストサービス
お問い合わせサービス
データソースサービス
応答サービス

MOAを使用すると、各サービスは独自の環境で実行され、開発者として、さらに重要なことに、建築家として、特定のニーズを解決するための最良の方法を自由に設計できます。

たとえば、Laravel環境で画像処理サービスを作成する場合、PHP-GD2拡張機能などのツールを使用する場合があります。これは、画像を処理する最も効率的な方法ではない場合があります。画像処理のニーズを処理するCサービスははるかに高速である可能性があり、確かに規模でより強力です。さらに詳しく説明するために、画像処理サービスの出力を取得し、DataStoreサービス、CloudStorageサービス、およびキューメールサービスに送信できます。

多くのCronジョブと、おそらくいくつかの個別のMVCアプリケーションとカスタムスクリプトを使用して、同じ課題を解決するために、それが過去に行ったことです（つまり、2年前）。前進する時が来ました。

スケーラビリティ

これは、問題が始まる（またはどこに向かっているのかによって終わる）場所です。一方では、モノリシックアプリケーションをスケーリングすることは困難であり、同じMVCスタックでますます多くのロジックを構築すると、よく構成されたアプリケーションに出くわすかもしれませんが、その複雑さは恐ろしいです。

一方、異なる言語で何千ものマイクロサービスを構築する場合、その混乱をどのように管理しますか？

複数の災害が報告されています。

さまざまなコンテナオーケストレーションツール（Kubernetes、Swarm、Mesosなど）、コンテナ展開サービス（GKEおよびAWS ECSなど）がありますが、Dockerアーキテクチャを習得した企業はほとんどいません。実際、Dockerまたはその他のコンテナテクノロジー（つまりGKE）を使用したインフラストラクチャの構築に関するいくつかのサクセスストーリーがあります。これらのケースのほとんどは、建築家、DevOps、DBA、およびエンジニアのリソースを引き受けることができる企業からのものです。それにもかかわらず、今のところ、よくアレンジされたエレガントなMOAを展開する方法について、無数の議論があります。この場合、1つのサイズはすべての状況に絶対に適していないため、挑戦を解決する多くの方法があります。

どちらにしても、この問題を単独で解決することはできません（DevOps ftw！）。比較的大規模に到達した後にのみ解決する必要があります。たぶん今は過剰設計に最適な時期ではありません。

今日（および複雑さや交通需要が低いアプリケーションを扱う人）の場合、幸せな中間アプローチは、多くの典型的なサービスをサードパーティのプロバイダーにオフロードすることです。現在、ほとんどすべてがサービスとして利用可能になりました。バックグラウンドジョブ、画像処理、認証、データ分析、ロギング、電子メール送信、キューイングシステムは同じMVCスタックに構築する必要はありません。アーキテクトは、毎月の低い料金でSaaSシステムにオフロードできるものを考慮する必要があります（つまり、 Algolia Search）または、迷惑な画像処理を処理するいくつかのクラウドスペースで実行されるカスタムビルドドッカーサービス。

ここでのポイントは、あなたが再アーカイトプロジェクトに真正面から飛び込み、今日持っているものすべてを捨てないでください、そしてあなたが想像できるところならどこでもDockerの群れをリリースするべきではないと思います。改善の基礎は、可能な部分を切り離し、システム内のボトルネックを理解し、これらの問題領域に懸念の分離の概念を適用することにより、徐々に導入できます。

結論

2017は、コンテナベースのMOAに関する会話と生産展開を増やします。 Golangやノードを使用するDockerについての私の意見とナンセンスは、PHPが「死んでいる」などのことではありません...開発者としてパックの先を行く必要があると感じています。それでは、なぜゴランを学んでみませんか？小さなコンテナ化されたアプリケーションを開発するのに最適です（フットプリントが小さいため、速度が高速で、並列処理があります）。ノードとゴランは楽しいです。なぜなら、あなたがそれらを結びつける大規模な部族の一部である小さなサービスを構築し、必要に応じてDockerコンテナの壮大な群れとして公開できるからです。ただし、これらの素晴らしい最先端のソリューションと言語はすべて、PHPがもはや関連性または「死んでいる」ことを意味するものではありません。しばらくの間、MVCスタックとAPIのエンドポイントを確実に構築します。

MOAで解決されていない問題の1つは、コンテナがバックエンドのモノリシックアプリケーションを排除するのに役立ちますが、フロントエンド層、UI、またはビューの多くの建築上の問題に直面していることです。非常に強力なバックエンドアプリケーションを構築できますが、最終的にはJSONで応答します。これは、クライアントアプリケーションで何らかの形でレンダリングする必要があります。最終的な応答オブジェクトは、単純なPHP（例えば、ルーメン駆動のエンドポイント（URL））またはメッセージインターフェイスによって分離された一連の決定および処理ユニットからのものですか？それは本当にあなたのニーズとあなたのアプリケーションの要件に大きく依存します。

今年、Laravelについて学び、Docker、Golangに焦点を当て、パイプラインの展開に絶対に焦点を当ててください。特にMVCアプリケーションを構築する場合、ローカルから生産への変換は、しばらくの間よりスムーズになるはずです。

PHP MVCフレームワークに関するFAQ

PHPのMVCフレームワークは何ですか？

PHPのModel-View-Controller（MVC）フレームワークは、アプリケーションを3つの相互に関連するコンポーネントに分割する設計パターンです。モデルコンポーネントは、すべてのデータに関連するロジックを使用してユーザーに対応します。ビューコンポーネントは、アプリケーションのすべてのUIロジックに使用されます。一方、コントローラーは、モデルとビューコンポーネントの間のインターフェイスとして機能し、すべてのビジネスロジックと着信要求を処理します。

なぜPHP開発にMVCフレームワークを使用する必要があるのですか？

MVCフレームワークを使用したPHP開発には、多くの利点があります。懸念の明確な分離を提供するため、コードの維持と理解が容易になります。また、コードの再利用性とスケーラビリティを促進し、開発者が堅牢で大規模なアプリケーションを作成できるようにします。さらに、MVCフレームワークには、データベースの抽象化、フォーム検証、セッション、Cookie処理などのタスクを容易にするために、組み込みのツールとライブラリが付属していることがよくあります。

2017年のPHP MVCフレームワークのトップは何ですか？

2017年、PHP MVCのトップフレームワークには、Laravel、Symfony、Codeigniter、Yii2、CakePhpが含まれます。 Laravelは、エレガントな構文、強力な機能、活気のある開発者コミュニティで特に人気があります。 Symfonyは、高度な柔軟性とモジュラーアーキテクチャにも広く使用されています。

私のプロジェクトに適したPHP MVCフレームワークを選択する方法は？

適切なPHP MVCフレームワークを選択すると、プロジェクトの規模と複雑さ、チームの専門知識、フレームワークのコミュニティとサポート、パフォーマンスとスケーラビリティ、学習曲線など、いくつかの要因に依存します。決定を下す前に、これらの要因に基づいて、さまざまなフレームワークを研究し、比較することをお勧めします。

MVCモードはPHPフレームワークでどのように機能しますか？

PHP MVCフレームワークでは、ユーザーがリクエストを送信すると、最初にコントローラーに移動し、データを処理するための適切なモデルを識別します。次に、モデルはデータベースと対話し、データを処理し、コントローラーに送り返します。次に、コントローラーは対応するビューをロードし、ユーザーフレンドリーな形式でユーザーにデータを提示します。

laravelとは何ですか？なぜそれはそんなに人気があるのですか？

Laravelは、エレガントな構文とリッチな機能で知られるPHP MVCフレームワークです。ルーティング、認証、セッション、キャッシュ、その他のタスクのためのさまざまなツールを提供します。 Laravelには、活気のあるコミュニティと、開発者にとって人気のある選択肢となる大量のドキュメントがあります。

PHP MVCフレームワークの学習曲線は何ですか？

PHP MVCフレームワークの学習曲線は異なる場合があります。 LaravelやCodeigniterのようないくつかのフレームワークは、それらのシンプルさで知られており、比較的簡単に学ぶことができます。 SymfonyやYii2などの他のフレームワークは、機能と概念が複雑であるため、習得するのにもっと時間がかかる場合があります。