PHP の発明者は MVC と Web サイトのデザイン アーキテクチャについて語ります。彼は MVC を使用した PHP をサポートしていないようです。

Q: ますます多くの Web 2.0 Web サイトがアプリケーション プラットフォームに移行していますが、そのようなプラットフォームを構築するための鍵は何だと思いますか?

A: 簡単に言うと、アプリケーション プラットフォームは API です。Ajax または Web 2.0 タイプの Web サイトは、アプリケーション プラットフォーム上の API を使用して、ビジュアル インターフェイスのインタラクティブな効果を作成します。たとえば、Yahoo Mail は、単純な Request 呼び出しを通じて後続の電子メールを読み取ります。この種の Web サイトを構築する場合、Web サイトの発展を決定するパフォーマンスではなく、問題をどのように解決するかを計画するかによって、Web サイトの将来の拡張性 (スケーラビリティ) が決まります。

Q: スケーラブルになるように Web サイトの構造を計画するにはどうすればよいですか?

A: Web サイトのアプリケーションを数十の独立した小さなプログラムに分割し、フロントエンドは API を通じてサービスを提供し、バックエンドはアプリケーション エンジンになります。これは自然にスケーラビリティにつながります。アプリケーションの各部分には異なる使用レベルがあり、異なるスケーリング レベルが必要であり、それを処理するには異なるメカニズムが必要であるためです。 Yahoo Mailを開発する場合、アドレスサービスプログラム、メール読み取りサービス、メール送信サービスを開発する必要がありますが、メール送信プログラムはメール読み取りプログラムとは関係がありません。 Yahoo の規模を考えると、スケーラブルにするためには、これらのタスクを完全に分離する必要があります。

Q: この方法で Web サイトを計画する上で最も重要な鍵は何ですか?

A: 重要なのは、すべてを同じ大きなバスケットに入れるのではなく、個別のモジュール式の独立したエンドポイントを構築する必要があるということです。現在の MVC アーキテクチャ (MVC フレームワーク) のほとんどの開発フレームワークは、いわゆるフロントエンド コントローラー (フロント コントロール) を使用します。ブラウザーが Request リクエストを行うたびに、このフロントエンド コントローラーが呼び出され、次にフロントエンド コントローラーが呼び出されます。エンドコントローラーは、ユーザーが実行したいプログラムを識別します。そんなことをしてもまったく意味がありません。

ブラウザレベルでは、プログラムはユーザーが何をしたいのかを完全に知ることができます。たとえば、ユーザーが手紙を読みたいだけの場合、プログラムはリクエストをサーバーに送信して実行する必要はありません。サーバーはユーザーが何を読みたいのかを決定します。この種の意思決定作業をブラウザーから取り出してサーバーで処理させると、ユーザーにとって実際には使用しない作業に多くのサーバー リソースが無駄になります。スケーラビリティはアーキテクチャから生まれ、多くの開発フレームワークはすべてを結び付けてアーキテクチャを制限します。間違った開発フレームワークを選択すると、スケーラビリティが得られません。

Q: MVC モデルは Web サイトのスケーラビリティに役立たないということですか?

A: MVC モデルは、ページ コントローラー (ページ コントロール) レベルでの使用により適しています。基本的に各Webコントローラは独立したモジュールであり、メール読み込みとアドレスチェックは別のWebコントローラとなるため、メール読み込みプログラムがアドレスチェックプログラムを干渉することはありません。したがって、MVC パターンを使用して各エンドポイントに小さな Web コントローラーを作成することに問題はありません。ただし、MVC モデルを使用するほとんどのフレームワークは、デフォルトで Web コントローラーではなくフロントエンド コントローラーを使用します。この MVC モデルは、小規模な Web サイトまたは単一サーバーの Web サイトにのみ適しています。

Q: 開発フレームワークはどのように選択しますか?

A: フレームワークは使用しません。ただし、フレームワーク全体を適用するのではなく、これらの開発フレームワークの中から必要な機能を見つけ出し、必要なプログラムモジュールを使用したり、その中の設計思想を参考にしたりすることになります。私がこれまで見てきたフレームワークのほとんどは、効率的な拡張性と MOD 対応性の構築に焦点を当てていませんでした。

Q: 開発者にはフレームワークやアーキテクチャは必要ありませんか?

A: ウェブサイトには構造が必要です。フレームワークは問題を解決するための手段です。ただし、通常は機能しないフロントエンド コントローラーに関するすべての問題を解決するための一般的なフレームワークは必要ありません。すべての問題は異なるため、フレームワークをブートストラップし、適切な設計パターンを使用して、対処している実際の問題に直接対処する必要があります。たった一種類の車を生産して、どうして世界中の人々のニーズに応えることができるのでしょうか？

フレームワークを使用してプロトタイプ システムを開発するのは問題ありませんが、すべてを実際の製品に適用しないでください。フレームワークから始めるほうが簡単ですが、フレームワーク全体を解体し、実行時チェックを削除し、不要な機能を削除して、使用するプログラム モジュールだけを残す必要があります。将来の拡張性を提供しない汎用フレームワークは必要ありませんが、最初から始める必要はなく、中間のものが必要です。

Q: Web サイトの拡張ニーズを計画するのにどれくらい時間がかかりますか?

A: 私は将来のことを考えすぎるのがいつも嫌いです。未来を予測できないと、将来についての決定を下すこともできません。
インターネットの変化は非常に速いので、私は通常半年以内にしか計画を立てません。半年後に何が起こるかを今決めてしまうと、誤った決定を招き、事態をさらに悪化させる可能性があります。現在の問題を解決するのではなく、将来起こる問題を想像するのであれば、目の前にある問題を解決して、自分の製品に真剣に取り組みたいと思います。今必要です。

Q: では、建築家が従うべきガイドラインはありますか?

A: 最も重要な原則は、プログラム モジュールをどのように割り当てるかを慎重に検討し、プログラムを可能な限り小さなコンポーネントに分解し、適切な API を調整することです。計画する必要があるのは、ユーザー エンドポイントのようなものです。ブラウザリクエストのタイプは何ですか?アプリケーションはどのように応答すべきでしょうか?カットできますか？これらのタスクを完全に別のサーバーに分散することは可能ですか?同じサーバー上でも、ユーザー エンドポイントの観点からアプリケーションを設計できます。いつか、規模が大きくなったときに、フロントエンド サーバーに 2 台目のサーバーを簡単に追加できるようになります。トラフィックを保存せずに共有できます。あらゆるデータ。開発者がよく犯す最大の間違いは、プログラム コード間の相互関係が深すぎることです。これにより、非常にクリーンな API を調整することが困難になります。開発者は遅い API を抽出してセカンダリ サーバーに置くことができなくなり、プライマリ サーバーは必要な API のみを実行することになります。

Q: 切断サービスと分解プロセスの難しさは何ですか?

A: 始める前に問題をよく理解する必要があります。プログラムの最初のバージョンを書き終えると、その後の問題を解決し始めることはほとんど不可能であり、困難です。質問がコロコロ変わるので本当に難しいです。ただし、単純なアーキテクチャから開始し、この精神を維持してアプリケーション モジュールを分離する場合は、ウェブサイトが変更されるたびに、問題の変更はほんの一部にのみ影響します。その場所をよく知ることができ、問題を直接解決できるようになります。レゴゲームと同じように、小さな積み木をひとつずつ作っていくと、足りないところがあれば、小さなピースを追加するだけで、全体をあまり変えずに済みます。

Q: スケーラビリティに加えて、Web サイトのパフォーマンスを向上させるにはどうすればよいですか?

A: パフォーマンスを向上させるには、まず各プログラムにどれくらいの時間がかかるかを知る必要があります。ユーザーが Request リクエストを送信した後、データの最初のバイトを受信するまでにどのくらい時間がかかりますか?多くの開発者は、この時間 (最初のバイトのレイテンシー) がどれくらいなのか、またはコードにどれくらいの時間がかかるのかを知りません。プロファイルを使用してパフォーマンスを追跡し、視覚的なパフォーマンス フローチャートを描画してボトルネックがどこにあるかを理解できます。

単一マシンの遅延を考慮しても、システムレベルの追跡プログラムを通じて、プログラムによって実行される各システムコール (System Call) にかかる時間を知ることができます。また、ブラウザーの遅延を考慮し、ユーザーが体感する実際の速度に基づいて Web ページの実行方法を改善する必要もあります。
新しい機能を追加するたびに、新しい機能が追加されるのに何ミリ秒かかるかを計算し、それだけの価値があるかどうかを検討できるようにしてください。

Q: では、Web サイトのセキュリティについてはどのような原則に注意を払う必要がありますか?

A: 基本的な精神は非常にシンプルで、データ ファイアウォールの概念を使用して Web サイトを設計するだけです。インターネット ファイアウォールはすべての通信ポートを厳密に監視し、セキュリティ上の懸念がないパケットのみの通過を許可します。しかし、Web サイト開発者は逆に、危険であると思われるコンテンツのみをブロックします。開発者は、外部から取得したデータを信頼できません。ファイアウォールの概念と技術を借用してデータ ファイアウォールを確立することで、Web サイトのセキュリティを向上させることができます。

Q: 優れた建築家の要件は何ですか?

A: テクノロジーをよく理解し、データ ストレージ メカニズムの設計など、あらゆる詳細を理解する必要があります。どのような種類のデータを保存できるか、ファイルのサイズ、データの量を理解する必要があります。保存できますか? 1 秒あたりどのくらいの速さで保存できますか?データをコピーするにはどうすればよいですか?フロントエンドでどのデータ形式を使用する必要があるかなど。アーキテクトは、DBA のように Oracle データベースのエラーを修正する方法を知る必要はありませんが、Oracle データベースの機能を理解できなければなりません。このような人はなかなか見つかりません。十分な経験を積むまでは、何度も失敗しなければなりません。

Q: 台湾にはまだ PHP 4 を使用している古い Web サイトがたくさんあります。今すぐ PHP 5 にアップグレードする必要がありますか?それともPHP 6を待ちますか?

A: できるだけ早く PHP 5 にアップグレードしてください。いくつかのテストと変更を加えれば、パフォーマンスとセキュリティを向上させることができます。なぜそうしないのでしょうか?オープンソース コミュニティの仕組みである PHP 6 を待つ必要はなく、リリース時期の約束はありません。 PHP バージョン 5.3 には多くの新機能が追加されています。できるだけ早く 4 から 5 にアップグレードすることが最も重要です。