Yii のクイックスタート (2)
- 黄舟オリジナル
- 2016-12-20 11:08:401038ブラウズ
3.コントローラー(Controller)
ControllerはCControllerクラスのサブクラスのインスタンスです。ユーザーの要求に応じてアプリケーションによって作成されます。コントローラーが実行されると、要求されたアクション (コントローラー クラス メソッド) が実行され、通常は必要なモデルが導入され、対応するビューがレンダリングされます。アクションは、名前が action で始まるコントローラー クラスのメソッドです (アクション + 大文字のアクション名)。
Controller クラス ファイルは protected/controllers/
Controllers に保存され、アクションは ID によって識別されます。
コントローラー ID は、「親ディレクトリ/サブディレクトリ/コントローラー名」の形式で、対応するコントローラー クラス ファイル protected/controllers/親ディレクトリ/サブディレクトリ/大文字のコントローラー名に対応します。
アクション ID は、アクションのメソッド名からアクションの接頭辞を除いたもの。
1. ルーティング
ユーザーはルーティングの形式で特定のコントローラーとアクションをリクエストします。ルートは、スラッシュで区切られたコントローラー ID とアクション ID によって接続されます。
たとえば、post/edit ルートは PostController とその編集を表します
アクション。デフォルトでは、URL http://hostname/index.php?r=post/edit はこのコントローラとアクションをリクエストします。
注: デフォルトでは、ルートは大文字と小文字が区別されます。アプリケーション構成で CUrlManager::caseSensitive を false に設定することで、ルーティングで大文字と小文字を区別しないようにできます。大文字と小文字を区別しないモードでは、コントローラー クラス ファイルを含むディレクトリ名は小文字であり、コントローラー マップとアクション マップで使用されるキーは小文字であるという規則に従っていることを確認してください。
ルーティングの形式: コントローラー ID/アクション ID またはモジュール ID/コントローラー ID/アクション ID (ネストされたモジュールの場合、モジュール ID は親モジュール ID/サブモジュール ID)
2. コントローラーのインスタンス化
アプリケーションは使用します。次のルールによってコントローラー クラスとクラス ファイルの場所が決定されます:
1. CWebApplication::catchAllRequest が指定されている場合、コントローラーはこの属性に基づいて作成され、ユーザー指定のコントローラー ID は無視されます。これは通常、アプリケーションをメンテナンス状態にし、静的なプロンプト ページを表示するために使用されます。
2. ID が CWebApplication::controllerMap で見つかった場合、対応するコントローラー設定を使用してコントローラー インスタンスが作成されます。
3. ID が「path/to/xyz」の形式の場合、コントローラークラス名は XyzController と判断され、対応するクラスファイルは protected/controllers/path/to/XyzController.php となります。 。クラス ファイルが存在しない場合、404CHttpException がトリガーされます。
モジュールを使用する場合、アプリケーションはこの ID がモジュール内のコントローラーを表すかどうかを確認します。その場合、モジュール インスタンスが最初に作成され、次にモジュール内のコントローラー インスタンスが作成されます。
3. アクション
アクションは、アクションという単語を接頭辞として持つ名前のメソッドとして定義されます。より高度な方法は、アクション クラスを定義し、コントローラーがリクエストを受信したときにそのクラスをインスタンス化するようにすることです。これによりアクションを再利用できるようになり、再利用性が向上します。
1. アクション クラスを定義します。基本的な形式は次のとおりです。
class UpdateAction extends CAction
{
public function run()
{
// ここにアクション クラスを配置します
}
}
2.コントローラーに注意を向けさせるには、次の方法でコントローラー クラスの events() メソッドをオーバーライドする必要があります:
class PostController extends CController
{
public function events()
{
return array(
'edit'=>'application.controllers.post .UpdateAction',//「Application Folder/controllers/post/UpdateAction.php」ファイル内のクラスを使用して編集アクションを処理します
);
}
}
上に示すように、パス エイリアス「application.controllers .post.UpdateAction」を使用し、アクション クラス ファイルを「protected/controllers/post/UpdateAction.php」として指定します。
クラスベースのアクションを記述することで、アプリケーションをモジュール スタイルに編成できます。たとえば、次のディレクトリ構造を使用して、コントローラー関連のコードを整理できます:
protected/
controllers/
PostController.php
UserController.php
post/
CreateAction.php
ReadAction.php
UpdateAction.php
user/
CreateAction .php
ListAction.php
ProfileAction.php
UpdateAction.php
4. Filter
フィルターは、コントローラー アクションの実行前または後に実行されるように構成できるコードです。
アクションには複数のフィルターを含めることができます。複数のフィルターがある場合、それらはフィルター リストに表示される順序で実行されます。フィルターにより、アクションや後続の他のフィルターの実行が妨げられる場合があります。
フィルターはコントローラークラスのメソッドとして定義できます。フィルター メソッド名は filter で始まる必要があります。たとえば、既存の filterAccessControl メソッドは、accessControl という名前のフィルターを定義します。フィルター メソッドは次の構造を持つ必要があります:
public function filterAccessControl($filterChain)
{
// $filterChain->run() を呼び出して、後続のフィルターとアクションの実行を続行します。
}
$filterChain (フィルター チェーン) は、要求されたアクションに関連付けられたフィルターのリストを表す CFilterChain のインスタンスです。 filter メソッド内で $filterChain->run() を呼び出して、後続のフィルターとアクションの実行を続けることができます。
アクションと同様に、フィルターも CFilter またはそのサブクラスのインスタンスであるオブジェクトにすることができます。次のコードは、新しいフィルター クラスを定義します。
class PerformanceFilter extends CFilter
{
protectedfunction preFilter($filterChain)
{
//アクションが実行される前に適用されるロジック
return true; //アクションを実行すべきでない場合、ここでは false を返します
}
保護された関数 postFilter($filterChain)
{
//アクションの実行後に適用されるロジック
}
}
アクションにフィルターを適用するには、CController::filters() をオーバーライドする必要があります方法。このメソッドはフィルター構成の配列を返す必要があります。例:
class PostController extends CController
{
...
public function filters()
{
return array(
'postOnly + edit, create',//postOnly フィルターを適用してアクションを編集および作成します (これはメソッドベースのフィルター)
array( //フィルターの設定には配列が使用されます
'application.filters.PerformanceFilter - edit, create',//application.filters.PerformanceFilter フィルターを編集と作成を除くすべてのアクションに適用します (これはオブジェクトベースのフィルターです)
'unit'=>', / /フィルター オブジェクトのユニット属性値を秒に初期化します
),
);
}
}
上記のコードでは、postOnly と PerformanceFilter の 2 つのフィルターを指定しています。 postOnly フィルターはメソッドベースです (対応するフィルター メソッドは CController で定義されています)。一方、performanceFilter フィルターはオブジェクトベースです。パス エイリアス application.filters.PerformanceFilter は、フィルター クラス ファイルが protected/filters/PerformanceFilter であることを指定します。フィルター オブジェクトのプロパティ値の初期化に使用できるように、配列を使用して PerformanceFilter を構成します。ここでは、PerformanceFilter の単位属性値が秒に初期化されます。
プラス記号とマイナス記号を使用して、どのアクションにフィルターを適用するか、または適用しないかを指定できます。上記のコードでは、postOnly は編集および作成アクションにのみ適用され、PerformanceFilter は編集および作成以外のアクションに適用される必要があります。フィルター設定でプラス記号またはマイナス記号が使用されていない場合、このフィルターはすべてのアクションに適用されます。
5. モデル (Model)
モデルは CModel またはそのサブクラスのインスタンスです。モデルは、データとそれに関連付けられたビジネス ロジックを保持するために使用されます。
モデルは別個のデータオブジェクトです。データ テーブル内の行、またはユーザーが入力したフォームにすることができます。
データ オブジェクトの各フィールドはモデルの属性に対応します。各属性にはラベルがあり、一連のルールによって検証できます。
Yii はフォームモデルとアクティブレコードの 2 種類のモデルを実装します。どちらも同じ基本クラス CModel を継承しています。
フォーム モデルは CFormModel のインスタンスです。フォーム モデルは、ユーザーの入力から取得したデータを保持するために使用されます。このデータは多くの場合、取得、使用され、その後破棄されます。たとえば、ログイン ページでは、フォーム モデルを使用して、エンド ユーザーが提供したユーザー名とパスワードの情報を表すことができます。
アクティブ レコード (AR) は、オブジェクト指向スタイルでデータベース アクセスを抽象化するための設計パターンです。各 AR オブジェクトは、CActiveRecord のインスタンスまたはそのサブクラスの 1 つです。データテーブル内の行を表します。行のフィールドは、AR オブジェクトのプロパティに対応します。
6. ビュー
ビューは、主要なユーザー インタラクション要素を含む PHP スクリプトです。
ビューには名前があり、レンダリング時にその名前がビュー スクリプト ファイルを識別するために使用されます。ビューの名前は、ビュー スクリプト名と同じです。例: edit ビューの名前は、edit.php という名前のスクリプト ファイルから取得されます。レンダリングするには、ビューの名前を渡して CController::render() を呼び出します。このメソッドは、「protected/views/controller ID」ディレクトリで対応するビュー ファイルを検索します。
ビュー スクリプト内で、$this を通じてコントローラー インスタンスにアクセスできます。 「$this->プロパティ名」を使用して、ビュー内のコントローラーの任意のプロパティを取得できます。
次のプッシュ メソッドを使用してビューにデータを渡すこともできます:
$this->render('edit', array(
'var1'=>$value1,
'var2'=>$value2,
) ));
上記のメソッドでは、 render() メソッドが配列の 2 番目のパラメーターを変数に抽出します。この結果、ビュー スクリプトで変数 $var1 と $var2 に直接アクセスできるようになります。
1. レイアウト
レイアウトは、ビューを変更するために使用される特別なビュー ファイルです。通常、ユーザー インターフェイス ビューの共通部分が含まれています。たとえば、レイアウトにヘッダー部分とフッター部分を含めて、その間にコンテンツを埋め込むことができます。
...ここにヘッダー...
...ここにフッター...
$content は、コンテンツ ビューのレンダリング結果を格納します。
render() を使用すると、レイアウトが暗黙的に適用されます。ビュー スクリプト protected/views/layouts/main.php がデフォルトのレイアウト ファイルです。これは、CWebApplication::layout を変更することでカスタマイズできます。レイアウトなしでビューをレンダリングするには、renderPartial() を呼び出します。
2. 小さなオブジェクト
小さなオブジェクトは、CWidget またはそのサブクラスのインスタンスです。主にデータを表現するために使用されるコンポーネントです。ウィジェットは多くの場合、複雑で独立したユーザー インターフェイスを作成するためにビューに埋め込まれます。たとえば、カレンダー ウィジェットを使用して、複雑なカレンダー インターフェイスをレンダリングできます。ギズモにより、ユーザー インターフェイスがより再利用可能になります。
次のようにウィジェットを使用できます:
beginWidget('ウィジェット クラスのパス エイリアス'[,'属性の初期化値を含む配列']);?>
...コンテンツ本体これはウィジェットによって取得できます...
endWidget();?>
または
widget('ウィジェット クラス パス エイリアス '[, '属性の初期化値を含む配列']);?>
後者は、本文の内容を必要としないコンポーネントに使用されます。
ウィジェットを構成してパフォーマンスをカスタマイズできます。これは、CBaseController::beginWidget または CBaseController::widget を呼び出して初期化プロパティ値を設定することによって行われます。
これを行うには、これらのプロパティの初期化値を含む配列を渡します。配列のキーはプロパティの名前であり、配列の値はウィジェットのプロパティに対応する値です。以下に示すように:
$this->widget('CMaskedTextField',array(
'mask'=>'99/99/9999'
));
?>
CWidget を継承してオーバーライドするその init() メソッドと run() メソッドは新しいウィジェットを定義できます:
class MyWidget extends CWidget
{
publicfunction init()
{
// このメソッドは CController::beginWidget()
}
publicfunction run によって呼び出されます。 ()
{
// このメソッドは CController::endWidget() によって呼び出されます
}
}
ウィジェットはコントローラーと同様に独自のビューを持つことができます。
デフォルトでは、小さなオブジェクトのビュー ファイルは、小さなオブジェクト クラス ファイルのディレクトリを含むビュー サブディレクトリ (protected/components/views) の下にあります。これらのビューは、コントローラーと同様に、CWidget::render() を呼び出すことでレンダリングできます。唯一の違いは、ウィジェットのビューがレイアウト ファイルをサポートしていないことです。さらに、ウィジェット ビューの $this は、コントローラー インスタンスではなくウィジェット インスタンスを指します。
3. システムビュー
システムビューのレンダリングは通常、Yii のエラーとログ情報を表示するために使用されます。
システム ビューの名前付けは、いくつかのルールに従います。たとえば、「errorXXX」のような名前は、エラー番号 XXX の CHttpException を示すビューをレンダリングするために使用されます。たとえば、CHttpException が 404 エラーをスローした場合、error404 が表示されます。
framework/views の下に、Yii は一連のデフォルトのシステムビューを提供します。それらは protected/views/system の下に同じ名前のビューファイルを作成することでカスタマイズできます。
7. コンポーネント
Yii アプリケーションはコンポーネントに基づいて構築されます。コンポーネントは、CComponent またはそのサブクラスの 1 つのインスタンスです。コンポーネントの使用には、主にそのプロパティへのアクセスと、いつトリガーまたは処理するかが含まれます。基本クラス CComponent は、プロパティとイベントの定義方法を指定します。
1. コンポーネントのプロパティ
コンポーネントのプロパティは、オブジェクトのパブリック メンバー変数に似ています。読み取りと書き込みが可能です。
コンポーネントのプロパティを定義するには、コンポーネント クラスでパブリック メンバー変数を定義するだけです。
より柔軟な方法は、ゲッター メソッドとセッター メソッドを定義することです。例:
public functiongetTextWidth() // textWidth プロパティを取得します
{
return$this->_textWidth;
}
public functionsetTextWidth($value) // TextWidth プロパティを設定します
{
$this->_textWidth=$value;
}
上記のコードは、textWidth という名前の書き込み可能なプロパティを定義します (名前は大文字と小文字が区別されません)。プロパティが読み取られるときは getTextWidth() が呼び出され、その戻り値がプロパティ値になります。同様に、プロパティが書き込まれるときは setTextWidth() が呼び出されます。 setter メソッドが定義されていない場合、プロパティは読み取り専用となり、書き込まれると例外がスローされます。 getter メソッドと setter メソッドを使用してプロパティを定義する利点の 1 つは、プロパティの読み取りまたは書き込み時に追加のロジック (検証の実行、イベントのトリガーなど) を実行できることです。
注: ゲッター/セッターを通じて定義されたプロパティとクラス メンバー変数の間には微妙な違いがあります。プロパティ名は大文字と小文字が区別されませんが、クラス メンバー変数は大文字と小文字が区別されます。
2. コンポーネント イベント
コンポーネント イベントは、イベント ハンドラーと呼ばれるメソッドを値として使用する特別なプロパティです。イベントにメソッドを割り当てると、イベントが発生したときにそのメソッドが自動的に呼び出されます。したがって、コンポーネントの動作は、コンポーネント開発中に予期しない方法で変更される可能性があります。
コンポーネントイベントは、onで始まる名前で定義されます。 getter/setter メソッドを通じて定義されたプロパティと同様、イベント名では大文字と小文字が区別されません。次のコードは、onClicked イベントを定義します:
public function onClicked($event)
{
$this->raiseEvent('onClicked', $event);
}
$event (イベント パラメーターとして) ここでは CEvent またはそのサブクラス インスタンスです。 。
次のようにこのイベントにメソッドを割り当てることができます:
$component->onClicked=$callback;
ここで $callback は有効な PHP コールバックを指します。グローバル関数またはクラス内のメソッドにすることができます。後者の場合は、array($object,'methodName') のように配列として指定する必要があります。
イベント ハンドルの構造は次のとおりです:
関数メソッド名 ($event)
{
...
}
$event ここで、イベントを説明するパラメーターです (raiseEvent() 呼び出しから取得されます)。 $event パラメータは、CEvent またはそのサブクラスの 1 つのインスタンスです。少なくとも、誰がイベントをトリガーしたかに関する情報が含まれています。
イベント ハンドラーは、PHP 5.3 以降でサポートされる匿名関数にすることもできます。例:
$component->onClicked=function($event) {
...
}
ここで onClicked() を呼び出すと、onClicked イベントが (onClicked() 内で) トリガーされ、添付されたイベントハンドルは自動的に呼び出されます。
イベントは複数のハンドルにバインドできます。イベントが発生すると、これらのハンドラーはイベントにバインドされた順序で実行されます。ハンドラーが後続のハンドラーの実行を禁止すると決定した場合、$event->handled を true に設定します。
3. コンポーネントの動作
コンポーネントにはミックスインのサポートが追加され、1 つ以上の動作をバインドできます。ビヘイビアーは、特殊な継承 (つまり、通常のクラスの継承) ではなく、関数を収集することによってバインドされているコンポーネントによってメソッドを継承できるオブジェクトです。コンポーネントは、「多重継承」を通じて複数の動作のバインディングを実装できます。
Behavior クラスは IBehavior インターフェイスを実装する必要があります。 ほとんどの動作は CBeavior から継承できます。動作をモデルにバインドする必要がある場合は、モデル専用のバインド機能を実装する CModelBehavior または CActiveRecordBehavior から継承することもできます。
ビヘイビアーを使用するには、まずこのビヘイビアーのattach() メソッドを呼び出してコンポーネントにバインドする必要があります。次に、コンポーネントを通じてこの動作メソッドを呼び出すことができます:
// $name はコンポーネント内の動作を一意に識別します
$component->attachBehavior($name,$behavior);
// test() は動作メソッド内にあります。
$component->test();
バインドされた動作は、コンポーネント内の通常のプロパティと同様にアクセスできます。たとえば、tree という名前のビヘイビアーがコンポーネントにバインドされている場合、次のコードを通じてこのビヘイビアーへの参照を取得できます。
$behavior=$component->tree;
// は次のコードと同じです:
// $behavior=$component->asa('tree');
現時点では、この動作を一時的に禁止できますそのメソッドはコンポーネント内で失敗します。例:
$component->disableBehavior($name);
// 次のコードは例外をスローします
$component->test();
$component->enableBehavior($name);
//今すぐ使用できます
$component->test();
同じ名前の 2 つの動作を同じコンポーネントにバインドすることができます。この場合、最初にバインドするアクションが優先されます。
ビヘイビアーはイベントと併用するとさらに強力になります。ビヘイビアーがコンポーネントにバインドされている場合、ビヘイビア内の一部のメソッドをコンポーネントの一部のイベントにバインドできます。このようにして、動作を有機的に観察したり、コンポーネントの通常の実行フローを変更したりできます。
ビヘイビアーのプロパティには、ビヘイビアがバインドされているコンポーネントを通じてアクセスすることもできます。これらのプロパティには、パブリック メンバー変数と、ゲッターやセッターを介して設定されたプロパティが含まれます。たとえば、ビヘイビアーにプロパティ xyz があり、このビヘイビアーがコンポーネント $a にバインドされている場合、式 $a->xyz を使用してこのビヘイビアーのプロパティにアクセスできます。
8. モジュール
モジュールは、モデル、ビュー、コントローラー、その他のサポート コンポーネントを含む独立したソフトウェア ユニットです。多くの点で、モジュールはアプリケーションに似ています。主な違いは、モジュールは個別にデプロイできず、アプリケーション内に存在する必要があることです。ユーザーは、通常のアプリケーションのコントローラーにアクセスするのと同じように、モジュール内のコントローラーにアクセスできます。
モジュールはいくつかのシナリオで役立ちます。大規模なアプリケーションの場合は、アプリケーションを複数のモジュールに分割する必要がある場合がありますが、各モジュールは独立して保守およびデプロイできます。ユーザー管理やコメント管理などの一部の共通機能はモジュールの形式で開発できるため、将来のプロジェクトで簡単に再利用できます。
1. モジュールを作成します
モジュールはディレクトリ内に編成され、ディレクトリ名はモジュールの一意の ID になります。モジュール ディレクトリの構造は、アプリケーションのベース ディレクトリと非常によく似ています。 fourm モジュールの一般的なディレクトリ構造は以下のとおりです。
forum/ モジュール フォルダー
ForumModule.php モジュール クラス ファイル
components/ には再利用可能なユーザー コンポーネントが含まれます
views/ には小さなオブジェクトのビュー ファイルが含まれます
controllers/ にはコントローラー クラス ファイル
DefaultController が含まれます。 php デフォルトのコントローラー クラス ファイル
extensions/ サードパーティの拡張機能が含まれます
models/ モデル クラス ファイルが含まれます
views/ コントローラー ビューとレイアウト ファイルが含まれます
layouts/ レイアウト ファイルが含まれます
default/ DefaultController ビュー ファイルが含まれます
index.php ホームページ ビュー ファイル
モジュールにはCWebModuleから継承したモジュールクラスが必要です。クラスの名前は式 ucfirst($id).'Module' によって決定されます。$id はモジュールの ID (またはモジュールのディレクトリ名) を表します。モジュール クラスは、モジュール コード間で共有できる情報を保存する中心的な場所です。たとえば、CWebModule::params を使用してモジュール パラメーターを保存したり、CWebModule::components を使用してモジュール レベルのアプリケーション コンポーネントを共有したりできます。
2. モジュールを使用する
モジュールを使用するには、まずアプリケーションのベース ディレクトリの modules フォルダーにモジュール ディレクトリを配置します。次に、アプリの modules 属性でモジュール ID を宣言します。たとえば、上記のフォーラム モジュールを使用するには、次のアプリケーション構成を使用できます:
return array(
...
'modules'=>array('forum',...),
... ..
);
モジュールは初期プロパティ値を使用して構成することもできます。このアプローチは、アプリケーション コンポーネントの構成と非常によく似ています。たとえば、フォーラム モジュールはモジュール クラスに postPerPage というプロパティを持つことができ、これはアプリケーション構成で次のように構成できます:
return array(
...
'modules'=>array(
'forum '= >array(
'postPerPage'=>20,
),
),
......
);
モジュールのインスタンスには、現在アクティブなコントローラーの module プロパティを通じてアクセスできます。モジュール インスタンス内では、モジュール レベルで共有される情報にアクセスできます。たとえば、上記の postPerPage 情報にアクセスするには、次の式を使用できます:
$postPerPage=Yii::app()->controller->module->postPerPage;
// たとえば、$this は次を指します。コントロール コントローラー インスタンスでは、次のステートメントを使用できます
//$postPerPage=$this->module->postPerPage;
モジュール内のコントローラー アクションは、「モジュール ID/コントローラー ID/アクション ID」を通じてルーティングできます。 「モジュールID/コントローラクラスファイルが格納されているサブディレクトリ名/コントローラID/アクションID」にアクセスします。たとえば、上記のフォーラム モジュールに PostController という名前のコントローラーがあると仮定すると、forum/post/create ルートを通じてこのコントローラーの作成アクションにアクセスできます。このルートに対応する URL は http://www.example.com/index.php?r=forum/post/create です。
3. ネストされたモジュール
モジュールは無限にネストできます。これは、あるモジュールに別のモジュールを含めることができ、この別のモジュールに他のモジュールを含めることができることを意味します。前者を親モジュール、後者をサブモジュールと呼びます。サブモジュールは、前にアプリケーション構成でモジュールを定義したのと同じように、親モジュールの modules 属性で定義する必要があります。
サブモジュール内のコントローラー アクションにアクセスするには、ルートの親モジュール ID/サブモジュール ID/コントローラー ID/アクション ID を使用する必要があります。
9. パスエイリアス
パスエイリアスは Yii で広く使用されています。パス エイリアスは、ディレクトリまたはファイルのパスに関連付けられます。これは、広く使用されている名前空間形式と同様のドット構文で指定されます:
RootAlias.path.to.target
ここで、RootAlias は既存のディレクトリのエイリアスです YiiBase::setPathOfAlias() を呼び出すことで、新しいディレクトリを定義できます。パスの別名。便宜上、Yii は以下のルートエイリアスを事前定義します:
system: Yii フレームワークディレクトリを表します;
application: アプリケーションのベースディレクトリを表します;
webroot: エントリスクリプトファイルが存在するディレクトリを表します。位置しています。
ext: すべてのサードパーティ拡張機能を含むディレクトリを表します。
さらに、アプリケーションがモジュールを使用する場合、(Yii) は各モジュール ID のルート エイリアスも定義し、対応するモジュールのルート ディレクトリを指します。
YiiBase::getPathOfAlias() を使用すると、エイリアスを対応するパスに変換できます。
エイリアスを使用すると、クラス定義を簡単にインポートできます。たとえば、CController クラスの定義をインクルードしたい場合は、次のコードを呼び出すことができます
Yii::import('system.web.CController');
インポート メソッドは include や require とは異なります。もっと効率的。インポートされたクラス定義は、初めて参照されるまで実際には組み込まれません。同じ名前空間を複数回インポートする場合も、include_once や require_once よりもはるかに高速になります。
次の構文を使用してディレクトリ全体をインポートすることもできます。これにより、このディレクトリ内のクラス ファイルが必要に応じて自動的に組み込まれます。
Yii::import('system.web.*');
インポートに加えて、エイリアスは他の多くの場所のクラスも指します。たとえば、パスエイリアスを Yii::createComponent() に渡して、対応するクラスのインスタンスを作成できます。クラス ファイルがこれまでにインクルードされたことがない場合でも。
パスのエイリアスと名前空間を混同しないでください。名前空間は、たとえ同じ名前であっても、クラス名の論理的な組み合わせを指します。パス エイリアスは、クラス ファイルまたはディレクトリを指すために使用されます。パスのエイリアスは名前空間と競合しません。