ホームページ >バックエンド開発 >PHPチュートリアル >Yii Framework 公式ガイド シリーズ 15 - 基本: MVC のベストプラクティス
Model-View-Controller (MVC) はほぼすべての Web 開発者に知られていますが、実際のアプリケーション開発で MVC を適切に使用する方法は、依然として多くの人を困惑させています。 MC の背後にある中心的なアイデアは、コードの再利用性とロジックとビューの分離です。このセクションでは、Yii フレームワークを使用する場合に、MVC をより効果的に使用してアプリケーションを開発する方法について説明します。
より分かりやすく説明するために、Web アプリケーションには次のサブアプリケーションが含まれていると仮定します。
フロントエンド: エンドユーザー向けのパブリック Web サイトインターフェイス
バックエンド: 全体を管理するための管理機能を提供します。 Web サイト アプリケーション。通常は管理者のみがアクセスして使用できます。
コンソール: ターミナル ウィンドウで実行できるコンソール コマンドを含むアプリケーション。
Web API: サードパーティがこのアプリケーションと対話するためのインターフェイスを提供します。 。
これらのサブアプリケーションはモジュールの形式で実装される場合もあれば、他のサブアプリケーションとコードを共有する Yii アプリケーションである場合もあります。
モデルは、Web アプリケーションの基礎となるデータ構造を表します。たとえば、LoginForm
モデルは両方で使用されます。アプリケーションのフロントエンドとバックエンド; News
モデルは、コンソール コマンド、Web API、およびアプリケーションのフロント/バックエンドで使用される可能性があるため、モデルLoginForm
model may be used by both the front end and the back end of an application; a News
model may be used by the console commands, Web APIs, and the front/back end of an application. Therefore, models
should contain properties to represent specific data;
should contain business logic (e.g. validation rules) to ensure the represented data fulfills the design requirement;
may contain code for manipulating data. For example, a SearchForm
model, besides representing the search input data, may contain a search
method to implement the actual search.
Sometimes, following the last rule above may make a model very fat, containing too much code in a single class. It may also make the model hard to maintain if the code it contains serves different purposes. For example, a News
model may contain a method named getLatestNews
which is only used by the front end; it may also contain a method named getDeletedNews
which is only used by the back end. This may be fine for an application of small to medium size. For large applications, the following strategy may be used to make models more maintainable:
Define a NewsBase
model class which only contains code shared by different sub-applications (e.g. front end, back end);
In each sub-application, define a News
model by extending from NewsBase
. Place all of the code that is specific to the sub-application in this News
model.
So, if we were to employ this strategy in our above example, we would add a News
model in the front end application that contains only the getLatestNews
method, and we would add another News
model in the back end application, which contains only the getDeletedNews
method.
In general, models should not contain logic that deals directly with end users. More specifically, models
should not use $_GET
, $_POST
, or other similar variables that are directly tied to the end-user request. Remember that a model may be used by a totally different sub-application (e.g. unit test, Web API) that may not use these variables to represent user requests. These variables pertaining to the user request should be handled by the Controller.
should avoid embedding HTML or other presentational code. Because presentational code varies according to end user requirements (e.g. front end and back end may show the detail of a news in completely different formats), it is better taken care of by views.
Views are responsible for presenting models in the format that end users desire. In general, views
should mainly contain presentational code, such as HTML, and simple PHP code to traverse, format and render data;
should avoid containing code that performs explicit DB queries. Such code is better placed in models.
should avoid direct access to $_GET
, $_POST
SearchForm モデルには、検索入力データを表す以外に、実際の検索を実装するための <code>search
メソッドが含まれる場合があります。🎜🎜🎜🎜場合によっては、上記の最後のルールに従うと、モデルが非常に太くなり、次の内容が含まれることもあります。また、モデルに含まれるコードが異なる目的に使用される場合、モデルの保守が困難になる可能性があります。たとえば、News
モデルに getlatestNews
という名前のメソッドが含まれる場合があります。 > フロントエンドでのみ使用され、バックエンドでのみ使用される getDeletedNews
というメソッドも含まれる場合があります。これは、小規模から中規模のアプリケーションには適しています。 、次の戦略を使用してモデルをより保守しやすくすることができます:🎜🎜🎜🎜異なるサブアプリケーション (フロントエンド、バックエンドなど) によって共有されるコードのみを含む NewsBase
モデル クラスを定義します。🎜🎜 🎜🎜 各サブアプリケーションで、NewsBase
を拡張して News
モデルを定義し、サブアプリケーションに固有のコードをすべてこの News に配置します。
モデル。🎜🎜🎜🎜 したがって、上記の例でこの戦略を採用する場合は、getlatestNews のみを含む <code>News
モデルをフロントエンド アプリケーションに追加します。 メソッドを追加し、バックエンド アプリケーションに別の News
モデルを追加します。これには、getDeletedNews
メソッドのみが含まれます。🎜🎜一般に、モデルにはロジックを含めるべきではありません。より具体的には、モデル🎜🎜🎜🎜は、エンドに直接関連付けられている $_GET
、$_POST
、またはその他の同様の変数を使用すべきではありません。モデルは、ユーザー リクエストを表すためにこれらの変数を使用しない、まったく別のサブアプリケーション (例: 単体テスト、Web API) によって使用される可能性があることに注意してください。ユーザー リクエストに関連するこれらの変数は、コントローラーによって処理される必要があります。 🎜🎜🎜🎜は、HTML やその他のプレゼンテーション コードの埋め込みを避ける必要があります。プレゼンテーション コードはエンド ユーザーの要件に応じて変化するため (たとえば、フロント エンドとバック エンドではニュースの詳細がまったく異なる形式で表示される場合があります)、ビューによって処理される方が適切です。 .🎜🎜🎜🎜2. ビュー🎜🎜ビューは、エンドユーザーが望む形式でモデルを提示する役割を担います。一般に、ビュー🎜🎜🎜🎜には、主に、トラバース、フォーマットするための単純な PHP コードが含まれます。 🎜🎜🎜🎜明示的な DB クエリを実行するコードを含めることは避けるべきです。そのようなコードはモデルに配置することをお勧めします。🎜🎜🎜🎜 $_GET
、$_POST への直接アクセスは避けるべきです。
、またはエンド ユーザーのリクエストを表す他の同様の変数。これはコントローラーの仕事であり、コントローラーやモデルによって提供されるデータの表示とレイアウトに焦点を当てる必要があります。リクエスト変数またはデータベースに直接アクセスします。🎜
は、コントローラーとモデルのプロパティとメソッドに直接アクセスできます。ただし、これはプレゼンテーションの目的でのみ実行してください。
ビューはさまざまな方法で再利用できます:
レイアウト: 共通のプレゼンテーション領域 (ページヘッダー、フッターなど) をレイアウトビューに配置できます。
部分ビュー: 部分ビュー (レイアウトによって装飾されていないビュー) を使用して、プレゼンテーション コードの断片を再利用します。たとえば、_form.php
部分ビューを使用して、モデルの作成ページと更新ページの両方で使用されるモデル入力フォームをレンダリングします。_form.php
partial view to render the model input form that is used in both model creation and updating pages.
Widgets: if a lot of logic is needed to present a partial view, the partial view can be turned into a widget whose class file is the best place to contain this logic. For widgets that generate a lot of HTML markup, it is best to use view files specific to the widget to contain the markup.
Helper classes: in views we often need some code snippets to do tiny tasks such as formatting data or generating HTML tags. Rather than placing this code directly into the view files, a better approach is to place all of these code snippets in a view helper class. Then, just use the helper class in your view files. Yii provides an example of this approach. Yii has a powerful CHtml helper class that can produce commonly used HTML code. Helper classes may be put in an autoloadable directory so that they can be used without explicit class inclusion.
Controllers are the glue that binds models, views and other components together into a runnable application. Controllers are responsible for dealing directly with end user requests. Therefore, controllers
may access $_GET
, $_POST
and other PHP variables that represent user requests;
may create model instances and manage their life cycles. For example, in a typical model update action, the controller may first create the model instance; then populate the model with the user input from$_POST
$_GET
、$_POST
、およびユーザーリクエストを表すその他の PHP 変数にアクセスできます。🎜🎜🎜🎜はモデル インスタンスを作成し、そのライフサイクルを管理できます。たとえば、典型的なモデル更新アクションでは、コントローラーは最初にモデル インスタンスを作成します。次に、$_POST
からのユーザー入力をモデルに設定します。モデルが正常に保存された後、コントローラーはユーザーのブラウザをモデルの詳細ページにリダイレクトする場合があります。モデルを保存する実際の実装は、コントローラーではなくモデル内に配置する必要があることに注意してください。🎜🎜🎜🎜埋め込み SQL ステートメントを含めることは避けてください。埋め込み SQL ステートメントはモデル内に保持することをお勧めします。🎜🎜🎜🎜 HTML などを含めることは避けてください。プレゼンテーションのマークアップ。これはビューに保存しておいたほうがよいでしょう。🎜🎜🎜🎜 適切に設計された MVC アプリケーションでは、コントローラーは非常に薄く、コードはおそらく数十行しか含まれていないことがよくあります。一方、モデルは非常に太く、データの表現と操作を担当するコードのほとんどが含まれています。これは、モデルによって表されるデータ構造とビジネス ロジックは通常、特定のアプリケーションに非常に固有であり、特定のアプリケーション要件を満たすように大幅にカスタマイズする必要があるためです。一方、コントローラー ロジックは、多くの場合、アプリケーション間で同様のパターンに従い、そのため、基礎となるフレームワークまたは基本クラスによって単純化される可能性があります。内容请关注PHP中文网(www.php.cn)!🎜