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ローカリゼーション管理、モデルモデル、Viewビュー、Controllerコントローラー（ホスト、サブドメイン名、URI、UA、IP、ACLをすべてサポートする必要あり）、Exception ErrorHandleエラー例外管理あり、セキュリティセキュリティ管理（Validator）データ検証、フィルターデータフィルター）状態管理（セッションセッション管理、キャッシュキャッシュ管理）。次に、アプリケーションに必要な基本的なクラス ライブラリがあり、その中でデータベースが最初にランクされます。このアーキテクチャでは、データベースはカーネルではなくクラス ライブラリに配置されます。その理由は主に 2 つあります。1 つは、ユーザーがフレームワーク自体を使用するか、ADODB などのサードパーティを使用するかを選択できることです。 、教義、そして人々。次に、Web サイトの規模が変化する場合、データベース レベルでの変更が最も速くなります。しかし、現在、このような標準化されたアーキテクチャを持つ開発フレームワークがどれだけあるでしょうか?
??? このことから、MVC アーキテクチャ モデルにおけるさまざまな誤解は 2 つの側面から生じていることがわかりました。
??? 1 つは人々の理解によって引き起こされます。 PHP 開発チームの技術の遅れと品質の低さが重要な理由の 1 つです。ソフトウェア アーキテクチャ、特にオブジェクト指向の設計パターンを理解していなければ、MVC を深く理解することは不可能です。
??? これは、PHP 自体の開発にも関係しています。PHP4 より前は、オブジェクト指向はサポートされていませんでした。 PHP はそのシンプルさから多くのユーザーを魅了しています。しかし、大規模な Web サイト開発で使用されると、JSP が面倒でロックされていると感じる人にとっては悪夢が始まります。
??? 2 つ目は、PHP 開発フレームワークの開発とオープン ソース テクノロジの開発は密接に関係しているということです。同時に、開発フレームワークは MVC に対して十分なサポートを提供できません。オープンソースコンポーネントなので、人々は MVC をさらに理解できません。同様に、PHP の ADODB を使用する場合、プログラム内でデータ モジュールとビジネス モジュールを分離する必要はありません。これは建築家の責任です。しかし、中国の PHP 業界にはネットワーク アプリケーション アーキテクトが何人いるでしょうか?例えば、Agile Walk Shanghaiのイベントでは、杭州の大企業の外国人CTOが「PHPにはフレームワークは全く必要ない」と講演したが、これは国内PHP業界の技術的後進性を反映していると言わざるを得ない。現実はとても残酷です。ソフトウェア業界の現状を直視するしかない。
???
???

?

???

1階 115300111 2011-03-20

はい、とても同意します

2階 yuhao_1202 2011-03-27

悪くないよ。同意する。