ホームページ >php教程 >php手册 >PHP チュートリアル: PHP フレームワークのディスカッション

PHP チュートリアル: PHP フレームワークのディスカッション

WBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWB
WBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBオリジナル
2016-06-21 08:56:421044ブラウズ

私はRORを1年間やっていますが、アジャイルの実践と合わせて(アメリカ人エンジニアとリモートで作業しているため)開発スピードが本当に速く、3人でコードを書いています。わずか半年でプロジェクトはほぼ終了です...

新しいプロジェクトが近づいているので、お客様はPHPとRailsのどちらを選択するかで悩んでいます。私もこの機会にPHPについて学ぶつもりです。 PHP。
プロジェクトはまだ高度にカスタマイズ可能であるため、成熟した CMS やその他のシステムを使用したいのですが、おそらく変更するのは無駄です。
ゼロから開発するのは遅すぎると感じます。そこで、オープンソース フレームワークから始めたいと思いました。

お互いを知るようになってから、新興の PHP フレームワークの一部は基本的にすべて Rails (または盗作、特にcakePHP、コピーが多すぎる) に基づいていることがわかりました。さらに、これらのフレームワークは非常に順調に開発されており、PHP コミュニティでますます人気が高まっています。 例えば、海外のcakePHP、国産のFleaphp、QeePHPなど、一つ一つ挙げることはしません

昨日cakePHPを使って簡単なデモを作りました。確かにRailsをコピーするのは非常に簡単です。 rake にもそれに代わるものがあります。移行とフィルター以外に対応するものは見つかりませんでした。 PHP を理解していない私でも、すぐに始めることができます。

私は、PHP が Rails を徹底的にコピーしたことを嘆く一方で、これらの盗作が実際に行われたことも嘆いています。 PHP開発の効率化を実現しました。 PHP 自体によるものですが、フレームワークの導入はパフォーマンスに比較的大きな影響を与えます。しかし、これらのフレームワークの出現は、PHP コミュニティを再編成する可能性を秘めています。 (少なくともお客様は、Rails を使用することは、cakePHP を使用するよりも悪いので、これ以上のリスクを招かないようにと私たちに言いました。また、米国のチームのいくつかが Rails から CakePHP に戻ったことも紹介しました。)

ああ、私は混乱しています。当時、Rails は PHP 市場をターゲットにしていると思っていました。 。 。今では、Rails のアイデアが PHP を救ったと感じています...

顧客を説得し続ける必要があると思いますか? それとも模倣レールを使用する必要がありますか?



マスター・ロビンの返信:
---------------------- -------------------------------------------------- --


PHP と Python/Ruby の操作メカニズムには本質的な違いがあります。PHP はすべてのリソースを初期化します (データベース リンクの作成、システム クラス ライブラリのロード、キャッシュの作成など)。 .) 各 HTTP リクエストが受信された後。処理後、すべてのリソースを解放します。Python/Ruby などの GC を使用したスクリプト言語とは異なり、Python/Ruby は最初の起動時にリソースを初期化し、後続のリクエストでリソースを再度初期化する必要はありません。 。

このメカニズムの違いによってもたらされる違いは次のとおりです。

1. コードがどれほど不良であっても、PHP で深刻なメモリ リークの問題が発生するのは非常に困難です。実行されるとすぐにすべてのリソースが解放されます。 Python/Ruby はメモリを再利用するために GC に依存する必要があるため、注意しないと、GC では解決できないメモリ リークの問題が依然として発生します。

2. PHP はリクエストごとにリソースを初期化する必要があり、非常にコストがかかります。そのため、PHP パーサー自体は非常に高速に動作しますが、一度複雑な PHP フレームワークを使用すると、リクエストが行われるたびにフレームワーク全体を初期化する必要があり、非常に複雑な PHP フレームワークを使用した結果、パフォーマンスが大幅に低下するだけです。全体的なパフォーマンスは Ruby にはるかに及ばない。これが、PHP コミュニティが長年にわたってフレームワークを使用することにあまり関心がなかった理由の 1 つです。

3. PHP はリクエストごとにリソースを初期化する仕組みのため、PHP が高度なクロスリクエスト機能を追加することも非常に困難ですが、これは逆に言うとまさにこれです。この制限により、PHP は比較的単純な Web 言語として保たれています。これが、PHP がインターネット上で最初の Web プログラミング言語になった理由であり、PHP が必ずしも悪いわけではありません。

要するに、PHP と Ruby の違いは依然として非常に大きく、実際には、Ruby と Python の間で比較する必要があります。

つまり、PHP が Rails のフレームワークアプローチの流れに従った後、実際には PHP を間違った道に導いたと私は考えています。そのため、Rails が PHP の開発を誤解させていると言ったほうがよいでしょう。ちなみに、DHH は Basecamp を書く前は PHP を使用していて、Ruby に切り替えた後も PHP 用の高速開発フレームワークを書きました。このフレームワークは実際には Rails のオリジナルのプロトタイプです。では、なぜ DHH は PHP に基づいて Rails を直接作成しなかったのでしょうか? Rails をリリースする前に Ruby に切り替える必要があったのでしょうか? PHP の動作メカニズムを見ると、PHP が複雑な Web 開発フレームワークを構築するのは明るい道ではないことがわかります。



声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。