PHP Web サイトの MVC アーキテクチャにおける誤解

PHP Web サイトの MVC アーキテクチャ モデルにおけるさまざまな誤解
MVC アーキテクチャ パターンは、もはや新しいテクノロジでも、新しい用語でもありません。ただし、社内のオープンソース PHP 開発フレームワーク、または国産の PHP オープンソース ソフトウェアをご覧いただければと思います。これらのコードの多くは MVC ではなく、模倣であることを見つけるのは難しくありません。その多くは MVC のための MVC です。または、MVC の一部の機能のみを提供します。本当の意味でのMVCではなく。もちろん、その理由の多くは、ソフトウェア開発者がデザイン パターンを理解しておらず、MVC の基本的な目的を理解していないことです。
したがって、まず MVC の基本的な目的を明確にしましょう:
1. 分業: MVC を使用すると、データベース開発、プログラム ビジネス ロジック開発、およびページ開発を分離できます。
ほとんどの人が MVC の利点について話すとき、それはこれに限定されます。 MVC は大規模なチームワークに役立つものにすぎないと私は信じています。実際、これは完全に間違いです。
2. 疎結合。デザインパターンを理解していなければ、疎結合が何を意味するのかもわかりません。もちろん、簡単に説明します:
モジュール部分をデータベース抽象化層、データ操作層、ビジネス ロジック層に分割します。これは最も単純なビジネス アーキテクチャです。この分離の利点は何ですか?
データベース抽象化レイヤーは通常、複数のデータベースをサポートします。この目的は、アプリケーションがデータベースを迅速に変更できるようにすることです。また、アプリケーションが他の種類のデータベースとやり取りすることも容易になります。
同時に、より強力に、大規模な Web サイトのサブデータベース操作とサブテーブル操作をサポートするリンク マネージャーも追加されます。
一般に、データベース抽象化レイヤーは、ウィザードを通じて静的 ORM レイヤーを生成したり、動的 ORM レイヤー (これが最新の DRYSQL モード) を直接提供したりできます。
ただし、ORM と CRUD に加えて、他のクエリもあります。 MVC では依然として、特別なデータ操作モジュールに MVC を書き込む必要があります。
なぜこんなことをするのですか？これが疎結合です。ある部分を変更しても、他の部分には影響しません。
データ モジュールとビジネス モジュールを混在させた場合、ある日データベースを変更する場合、巨大なモジュール部分のコードを変更する必要があることを想像してください。ただし、データ モジュールを独立させるには、データ モジュール部分の SQL ステートメントを変更するだけで済みます。
ビュー部分についても同様です。もともとPCブラウザ用に使われていたものなので、いつかモバイルページを追加したくなったら、それ以外はすべて共有するだけで済みますが、分離していない場合は新たに作成する必要があります。
この観点から、PHP はフレームワークの使用に適していないという人もいます。実際、多くの PHP はフレームワークなしでは動作しません。
その目標は達成されており、問題がある場合は 1 か所を変更するだけで済むことがわかります。多くの場所を変更するのではなく。
3. 共有と集中処理。
コントローラーは、完全にオブジェクト指向で設計されたプログラム フロー内のコンポーネントです。 PHP プログラムを記述する最も一般的な方法は、ヘッダーに SESSION モジュールが含まれ、その後にアクセス制御が続くということを覚えておいてください。ただし、ホスト名とサブドメイン名の制御を追加する場合は、含まれている各ページを再度含める必要があります。または、インクルード ファイルを SESSION モジュールまたはアクセス コントロール モジュールに追加します。その結果、プログラム ロジックは非常に複雑になります。エラーやジャンプがある場合、必然的にロードする必要のないページにジャンプします。
コントローラーの目的は、ページリクエストが最終的に必要なページに到達するようにすることです。そしてそれはオブジェクト指向プロセスに基づいています。
通常: コントローラーにはホスト、サブドメイン、IP、URL、および ACL のルーティング検出が必要です。現在、Web サイトにはブラウザーと携帯電話の両方が存在するため、UserAgent の検出も必要です。コントローラーは、リクエストをモジュール クラスのメソッド (イベント) に最も簡単にマップできる必要があります。
4. 完全なオブジェクト指向
ほとんどの MVC プログラムには 1 つのクライアント要求エントリ (ブートストラップ) しかなく、多くの場合、アプリケーションはこのファイルに基づいて構成または変更されます。それ以外はすべてクラスです。つまり、クライアントからサーバーへのイベント マッピングが実装されます。この目的は、アプリケーション プロセスを完全にオブジェクト指向のプロセスに標準化することです。プログラムの可読性とプログラマの独立性を確保します。
5. 現在人気のオープン API
優れた MVC アーキテクチャであれば、オープン API はデータ操作層インターフェイスを直接呼び出すことで実装でき、プログラム量も大幅に節約できます。同時に、コードの共通性と集中処理機能が向上します。問題がある場合は、1 か所を変更するだけで済みます。
6. 問題の表示: インターフェイスの要件は多様で常に変化するため、WEB モードのエンタープライズ アプリケーションではそのような変化が見られることがよくあります。残念ながら現在、PHP には .net や flex に似たビュー モードがまだありません。 Typstray や JFS などのコンポーネント指向のビュー モードを備えているのは JAVA だけであり、PHP には現在利用可能な成熟したオープン ソース製品がありません。 Smarty は Struts をコピーし、phpFACES は JFS をコピーしましたが、本質的には、PHP 言語の利点を十分に活用していませんでした。 phpFACES はさらに人気が低く、中国ではほとんど誰も使用していません。 FLAX RIA の影響と、JS フレームワークによってもたらされた新しい RIA テクノロジーは、バックエンド PHP と組み合わされていません。 JSP も遅れていますが、PHP も遅れています。人々は新しいオープンソースを必要としています。もちろん、phpFACES は DOJO をベースにして作成されたコンポーネントライブラリであるため、この分野の先駆者であると言えます。
7. プラグイン技術 : 優れた開発フレームワーク。すべての拡張はプラグインによって行う必要があります。しかし、現在プラグインをサポートしているフレームワークはどれだけあるでしょうか?公式の Zend はプラグイン構成ではなく、完全なセットであると言えます。これは純粋に技術的な誤解を招きます。もちろん、プラグインが最も多く、最も優れているのは symfony です。ただし、symfony の ORM は依然として Propel を使用しており、最新の DRYSQL テクノロジーを使用できません。プラグインに関する限り、多くの場合、ソフトウェアのアプリケーション、プロモーション、開発が制限されます。たとえば、有名な WordPress は完璧なアプリケーション プラグインを提供しますが、基礎となる開発フレームワークは非常に複雑です。最も単純なものは Mysql データベースにのみ使用できます。Oracle を使用したい人がいると、悪夢が始まります。したがって、優れたフレームワークはあらゆるレベルでプラグインをサポートする必要があります。プラグインは、データベース ドライバー プラグイン、データ モジュール プラグイン、キャッシュ ドライバー プラグイン、グラフィックス ライブラリ プラグインおよびその他の機能プラグインと、アプリケーション プラグインに大別できます。今日の時代では、プラグイン技術がなければ成功はありません。プラグインをサポートすることによってのみ無限の拡張を実現でき、多用途性は空論ではありません。しかし、国内の業界フォーラムを見る限り、プラグインインターフェースの実装技術に関する話題は見当たりません。 ！
8. 開発フレームワーク アーキテクチャ : WEB アプリケーション アーキテクチャの核となるのは、優れた開発フレームワークである必要があります。 アプリ オブジェクト、すべてを完了するためのエントリ ファイルの集約クラス。トランザクション、AutoLoader ローダー、uxConfig 設定ファイルの読み取り、uxLocale ローカリゼーション管理、モデル モデル、ビュー ビュー、コントローラー コントローラー (ホスト、サブドメイン名、URI、UA、IP、ACL をすべてサポートする必要があります)、Exception ErrorHandle エラーと例外の管理、セキュリティセキュリティ管理 (バリデータデータ検証、フィルターデータフィルター) 状態管理 (セッションセッション管理、キャッシュキャッシュ管理)。次に、アプリケーションに必要な基本的なクラス ライブラリがあり、その中でデータベースが最初にランクされます。このアーキテクチャでは、データベースはカーネルではなくクラス ライブラリに配置されます。その理由は主に 2 つあります。1 つは、ユーザーがフレームワーク自体を使用するか、ADODB などのサードパーティを使用するかを選択できることです。 、教義、そして人々。次に、Web サイトの規模が変化する場合、データベース レベルでの変更が最も速くなります。しかし、現在、このような標準化されたアーキテクチャを持つ開発フレームワークがどれだけあるでしょうか?
このことから、MVC アーキテクチャ モデルにおけるさまざまな誤解は 2 つの側面から生じていることがわかりました。
1 つは : 人々の理解によって引き起こされます。 PHP 開発チームの技術の遅れと品質の低さが重要な理由の 1 つです。ソフトウェア アーキテクチャ、特にオブジェクト指向の設計パターンを理解していなければ、MVC を深く理解することは不可能です。
これは、PHP 自体の開発にも関係します。PHP4 より前は、オブジェクト指向はサポートされていませんでした。 PHP はそのシンプルさから多くのユーザーを魅了しています。しかし、大規模な Web サイト開発で使用されると、JSP が面倒でロックされていると感じる人にとっては悪夢が始まります。
2 つ目は です。PHP 開発フレームワークの開発は、オープン ソース テクノロジの開発と密接に関係しています。この開発フレームワークは、MVC に対して十分な MVC アーキテクチャ サポートを提供できません。同時に、オープンソース コンポーネントのサポートが十分ではないため、MVC をさらに理解することができません。同様に、PHP の ADODB を使用する場合、プログラム内でデータ モジュールとビジネス モジュールを分離する必要はありません。これは建築家の責任です。しかし、中国の PHP 業界にはネットワーク アプリケーション アーキテクトが何人いるでしょうか?例えば、Agile Walk Shanghaiのイベントでは、杭州の大企業の外国人CTOが「PHPにはフレームワークは全く必要ない」と講演したが、これは国内PHP業界の技術的後進性を反映していると言わざるを得ない。現実はとても残酷です。ソフトウェア業界の現状を直視するしかない。