PHP が Web 開発言語として推奨されるのはなぜですか?
2016.01.08 22:59:56
いつからかわかりませんが、プログラマーは一斉に PHP を嘲笑し始め、「敬意を表して」PHP を「神の言語」と呼び、PHP は常に尊敬されていました。 「乱雑なコード」「抜け穴が多い」という悪い名前が付けられました。 Rails、ASP.NET MVC、Java Web、Django、Sinatra、PHP など、私がこれまでに接してきた Web 開発テクノロジの中で、PHP が推奨される Web 開発言語です。 ここでの「優先」は「最適」という意味ではなく、開発ツールスタック学習の選択プロセスにおいて優先すべき技術であることに注意してください。
なぜそんなことを言うのですか?たくさんの理由が一度に頭に浮かびますが、それらを整理してみましょう:
PHP をマスターするには、非常に中傷されている「乱雑なコード」プログラミング スタイルから始めることをお勧めします。おそらく、Web 開発テクノロジを直感的に理解した後、PHP と HTML の混合プログラミングから始めることをお勧めします。コードの組織と構造をリファクタリングすることで、よりネイティブな方法で Web の秘密を習得するのに役立ちます。では、よりネイティブな方法とは何でしょうか?典型的な 404 ステータス コードの例を示します。
PHP を使用した実装:
404.php
<?phpheader("HTTP/1.1 404 Not Found");include("404.html");exit;?>
404.html
<!DOCTYPE html><html lang="zh-CN"><head> <meta charset="utf-8"></head><body> <p>404页面。</p></body></html>
もう一度見てみましょうたとえば、ASP.NET MVC での実装:
public ActionResult Details(int id){ return HttpNotFound();}
これは適切にカプセル化されていますが、PHP メソッドと比較すると、ASP.NET MVC での実装は確かに抽象的であり、十分に直観的ではないことがわかります。そしてそれはコントロール内にあります プロセッサーで直接定義され、ジャンプされます。 PHP では、コード内のヘッダーの意味 (HTTP バージョン、ステータス コード、理由フレーズ) がすぐに理解されることは明らかです。
ところで、Rails の処理方法について説明します。
render :template => '......', :status => 404
PHP と同様に、JSP があります。ただし、JSP は多くの場合、JEE と組み合わせる必要があります。他の技術モジュールと組み合わせて使用する場合、システムは十分に大きくなり、長期的な準備が必要になります。 ASP.NET MVC や Rails などの他のフレームワークは抽象度が高いため、最初の選択肢として推奨されません。
Node.js について言及しなければなりません。Node.js は現在「フルスタック」の期待の技術として知られています。議論: 同時実行性とスレッド、プロセスなどとは何ですか?どちらが良いか悪いかについてここでコメントするつもりはありませんが、少なくとも PHP を使用すると、JavaScript だけでなく、もう 1 つのテクノロジーを習得できます。さらに、大規模企業向けの PHP の成熟した適用例も多数あります。
では、どこを指すかを入力するという「乱雑なコード」方法に常に固執する必要があるのでしょうか?もちろん、そんなはずはありません。 PHP が提供する OOP 機能は十分に強力であり、スキルと理解が一定のレベルに達すると、コードを OOP 方式で編成できます。 PHPの分野には、Laravel、CI、FuelPHP、Yii、Symfony、Zend Frameworkなど、さまざまなフレームワークがあり、標準化された開発を行うために任意のフレームワークを選択できます。 「乱雑なコード」の鍵はツール自体ではなく、人そのものです。 Java では不適切なコードを作成する可能性があることを知っておく必要があります。
PHP には多くの情報があります。
最後に、少し話が逸れましたが、RESTful Web サービスは標準の HTTP メソッド (GET/PUT/POST/) を使用するため、RESTful メソッドの人気が高まっていると考えました。 DELETE) を使用して Web サービス機能を抽象化すると、サーバーの焦点が MC に移り、サーバー ビュー テンプレートの適用が減少し、クライアントのサポート要件が増加します。たとえば、さまざまなフロントエンド ライブラリやフレームワークが急速に普及し、ますます多くのデマンド処理がフロントエンドに転送されて処理されるようになります。しかし、この状態は、頻繁で大規模なデータの変更と処理のシナリオと同様に、大量のページングなど、より具体的にはサーバー側 (テンプレート エンジンなど) で完了するのに適していると感じています。すべてのデータをブラウザに実装すると、パフォーマンスに大きな問題が確実に発生します。さらに、頻繁な Ajax 呼び出しやクライアント側のキャッシュ メカニズムの欠如もさまざまな問題を引き起こす可能性があります。さらに見てみると、シングル ページ アプリケーション (SPA) はあらゆるビジネス シナリオに適しているわけではありません。 サーバー側の観点もまだ多くあります。該当するフィールドのテンプレート。