MVC アーキテクチャにおける責任分担の原則

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

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

私は MVC のコントローラーを誤解しており、過去の経験に基づいて、すべてのビジネス ロジックはコントローラーのアクションに実装されることが当然だと思っていました。

その結果、各コントローラーには数千行のコードがあり、コードはますます肥大化しています。

ついに、私はコードを再構築することを決意しましたが、その原点は、オープン API インターフェイスの必要性でした。

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

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

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

MVC 設計原則

1. MVC

モデルとは- View-Controller (MVC) は、デザイン フレームワーク (デザイン パターン) です。

MVC の目標は、ビジネス ロジックをユーザー インターフェイスの考慮事項から分離することです。

これにより、開発者は他の部分に影響を与えることなく、各部分をより簡単に変更できます。

MVC では、モデルはデータとビジネス ルールを表し、ビューにはテキスト、フォームなどのユーザー インターフェイス要素が含まれ、コントローラーはモデルとビュー間の通信を管理します。

MVC はさまざまなプログラミング言語で実装されています。たとえば、J2EE アプリケーション開発では、

View は jsp によって実装されます。コントローラーはサーブレットで、現在は一般的に Struts によって実装されます。モデルは次のように実装されます。実装するエンティティ Bean。

2. 遭遇した問題

Yii Framework は、Ruby on Rails の ActiveRecord(AR) 概念を利用した人気のある PHP フレームワークです。

データベース内のすべてのテーブルは AR クラスを使用して、追加、削除、変更、クエリ操作を簡単に実行できます。

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

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

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

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

コントローラーがあるためは複数のアクションとなり、それぞれのアクションにはこのような業務処理があります。

ついに、コントローラーのコードが 1000 行を超えていることがわかりました。

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

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

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

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

その役割は、ユーザー入力を受け入れ、それを処理のためにすぐに他のクラスに転送することだけです。

このように、コントローラーは異なるインターフェースを提供することのみを担当するため、ビジネス ロジックを分離することができ、分離されたビジネスを簡単に再利用できます。

ビジネスのこの分離された部分は誰が処理するのでしょうか?答えは「モデル」です。

3. ビューの役割

ビュー部分は比較的明確であり、表示を担当します。

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

したがって、複雑な判断文や複雑な計算プロセスは、通常、View には表示されません。

単純なループ ステートメントと書式設定ステートメントを使用できます。たとえば、ブログのトップページにあるテキストリストは一種のループです。

PHP Web アプリケーションの場合、HTML は View のメイン コンテンツです。

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

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

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

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

さらに、View には通常、データベースへのクエリなどのデータ処理の準備がありません。

これらは通常、コントローラーに配置され、変数の形式でビューに渡されます。

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

4. モデルの責任

モデルにとって最も重要なことは、情報の保存と出力です。

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

データ、動作、およびメソッドがモデルの主な内容です。

実際の作業では、MVC の中でコード量が最も多いのは Model です。

モデルは、アプリケーションのビジネス ロジックもここで表現する必要があるため、ロジックの最も複雑な部分です。

モデルとコントローラーの区別に注意してください。

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

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

データ検証、パブリック定数、変数はすべてモデル層に配置する必要があります。

つまり、再利用できる属性やメソッドは、定義後にモデル層に配置する必要があります。 、どこでも使用されます。

モデルはリクエスト、セッション、その他の環境データにアクセスしてはなりません。これらはコントローラーによって挿入される必要があります。

優れたデザインは、太いモデルと細いコントローラーである必要があります。

5. コントローラーの責任

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

したがって、リクエストのアクセス コード ($_GET、$_POST など) をコントローラーに配置する必要があります。

コントローラーはユーザー要求データの取得に限定され、データに対する操作や前処理は実行しないでください。これはモデル内に配置する必要があります。

データ書き込み操作の場合、完了するには Model クラスのメソッドを呼び出す必要があります。

ユーザーのリクエストに応じて、ビューのレンダリングが呼び出されます。

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

6. 啓発

Yii Framework の公式ドキュメントには次の段落があります:

In a well-designed MVC application, controllers are often very thin, containing probably only a few dozen lines of code; while models are very fat, containing most of the code responsible for representing and manipulating the data.

つまり、リッチ モデルの方が優れています。

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