MVC アーキテクチャの意味と責任分担を説明する例

最近、Yii Framework の MVC フレームワークを使用したプロジェクトを担当したのですが、最初は非常に堅牢な構造だと思いました。

しかし、ビジネス ロジックについての理解を深めていくにつれて、問題の深刻さに気づき始めました。

私は MVC の Controller を誤解しており、過去の経験に基づいて、すべてのビジネス ロジックが Controller の action# に配置されることが当然だと思っていました。 ＃＃ 実装する。

その結果、各

Controller には数千行の コードが含まれ、ますます肥大化してきています。 ついに、私はコードを再構築することを決意しましたが、その原点は、オープン API インターフェイスの必要性でした。

現在のアーキテクチャでは、コードの再利用は基本的に不可能なので、多くの関数を何度も何度も記述する必要があり、これはとても容認できません。

オブジェクト指向プログラミングは教科書に載っているだけの用語ではありません。

実践を始めて初めて、オブジェクト指向の意識とグローバルな視点を持つことがいかに珍しいかに気づきました。

1 MVC とは正確には何ですか

Model-View-Controller (MVC) は、

の一種です。設計フレームワーク (設計パターン)

。 MVC の

目標

は、ビジネス ロジックをユーザー インターフェイスの考慮事項から分離することです。 これにより、開発者は他の部分に影響を与えることなく、各部分をより簡単に変更できます。

MVC では、

モデルは

データとビジネス ルールを表します
• ; ビューには ## が含まれます#ユーザー インターフェイス要素 (テキスト、フォーム
• など); コントローラーは、モデルとビュー間の 通信
• を管理します。 MVC はさまざまなプログラミング言語で実装されています。たとえば、J2EE アプリケーション開発では、
View は jsp によって実装される場合があります。コントローラーはサーブレットであり、現在は一般的に Struts で実装されます。モデルエンティティBeanによって実装されます。

2 遭遇した問題

Yii Framework は、Ruby on Rails を利用する人気の PHP フレームワークですActiveRecord(

AR# ＃＃） コンセプト。

データベース内のすべての table は、AR

クラスを使用して、追加、削除、変更、クエリ操作を簡単に実行できます。

AR をモデルとして扱い、models という名前のディレクトリに配置することをお勧めします。

そのため、テーブルに対応する AR を自動生成した後は、モデル層がすでに存在することを当然のことと考えていました。

実際には、

AR は単なる DAO (データ アクセス層) であり、モデル層ではありません

。

私たちの業務のほとんどすべてがコントローラーに置かれています。 ユーザーが送信したフォームに対してさまざまな論理的判断を行い、計算を実行し、AR をインスタンス化し、データを保存します...

Controller内に複数の

actionが存在するため、それぞれのaction

にこのような業務処理が存在します。

ついに、コントローラーのコードが 1000 行を超えていることがわかりました。 ある日突然、リーダーは、私たちのシステムがサードパーティのインターフェイスを呼び出して提供できるように、既存の古いシステム用の API をオープンする必要があると言いました。

サードパーティはパラメータを与えるだけでよく、システムは結果の値を与えるだけで、業務処理は意識しません。

悪い点は、コントローラーがすでにこれらのサービスを実装しているにもかかわらず、フォームの送信を受け入れることです。どうすれば SOAP XML ドキュメントも受け入れることができるのでしょうか?

コントローラーは、コンドームと同様、できるだけ薄くする必要があります。

その責任は、ユーザー入力を受け入れ、それをすぐに他のクラスに転送して処理することだけです。

。

このように、コントローラーは異なるインターフェイスを提供することだけを担当するため、ビジネス ロジックを分離することができ、分離されたビジネスを簡単に再利用できます。 ビジネスのこの分離された部分は誰が処理するのでしょうか?答えは Model

となるはずです。

3 View

View の責任は比較的明確で、表示を担当します。

表示インターフェイスと関係のないものはすべてビューに表示されるべきではありません。

したがって、通常は View に複雑な判断文や複雑な計算処理を含めるべきではありません。

単純なループ ステートメントと書式設定ステートメントを使用できます。たとえば、ブログのトップページにあるテキストリストは一種のループです。 PHP Web アプリケーションの場合、HTML が View

のメイン コンテンツです。

View はモデル記述メソッド を決して呼び出さないでください。

つまり、View は Model からデータを読み取るだけで、Model を書き換えることはありません。

したがって、ビューとモデルは切り離せないものであると言えます。

さらに、$_GET と $_POST は View から直接アクセスされず、Controller によって View に渡される必要があります。

さらに、View には通常、データベースへのクエリなどのデータ処理を準備するためのコンテンツが含まれていません。 これらは通常、コントローラーに配置され、変数の形式でビューに渡されます。

つまり、

ビューで使用されるデータは変数 です。

4 モデルの責任

モデル

にとって最も重要なことは、情報の保存と出力です。 たとえば、Post クラスには、ブログ投稿のタイトルを保存するために使用される title 属性が必要であり、削除操作も必要です。これらはすべてモデルの内容です。

データ、動作、およびメソッドは、Model

の主な内容です。 実際の作業では、MVC のコード量が最も多いのは

Model です。 モデルは、アプリケーションのビジネス ロジックもここで表現する必要があるため、ロジックの最も複雑な部分です。 モデルとコントローラーの区別に注意してください。

Model はビジネス ロジックを処理し、Controller は単に Model と View の間の関係を調整します。

ビジネスに関連するものであれば、モデルに含める必要があります。

#データ検証

、パブリック

定数と変数はすべてモデル層に配置する必要があります。言い換えると、再利用できる属性やメソッドはモデル層に配置し、一度定義すればどこでも使用できるということです。 モデルはリクエスト、セッション、その他の環境データにアクセスしてはなりません。これらはコントローラーによって挿入される必要があります。

優れたデザインとは、

太いモデルと薄いコントローラー

である必要があります。

5 コントローラーの責任

コントローラーの場合、主にユーザーのリクエストに応答し、使用するビューを決定します。準備が必要なデータ

を表示するために使用されるデータ。

したがって、request のアクセス コードは、$_GET

などのコントローラー

に配置する必要があります。 # #$_POST など。 コントローラーはユーザー リクエスト データの取得に限定する必要があります。データに対して操作や前処理を実行することはできません。これはモデル内に配置する必要があります。 データ書き込み操作の場合、完了するには Model クラスのメソッドを呼び出す必要があります。 ユーザーのリクエストに応じて、ビューのレンダリングが呼び出されます。

さらに、通常、HTML コードやその他のプレゼンテーション層のものは存在すべきではありません。、これがビューのコンテンツである必要があります。

6 啓発

Yii Framework の公式ドキュメントには次の段落があります:適切に設計された MVC アプリケーションでは、コントローラー多くの場合、モデルは非常に薄く、おそらく数十行のコードしか含まれていませんが、モデルは非常に太く、データの表現と操作を担当するコードの大部分が含まれています。モデルの方が優れています。

以上がMVC アーキテクチャの意味と責任分担を説明する例の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。