紹介 その3 モジュールについて
※この記事は以下の公式ドキュメントを元に書いています。
http://kohanaframework.org/3.2/guide/kohana/modules
Kohanaが用意しているモジュール
標準のモジュールはmodulesディレクトリの配下におさめられています。これらを有効にするにはapplication/bootstrap.phpで場所を指定します。コメントアウトを解除すると利用可能になります。自分で作ったモジュールは別の場所に配置して読み込ませることも可能です。
/**
* Enable modules. Modules are referenced by a relative or absolute path.
*/
Kohana::modules(array(
// 'auth' => MODPATH.'auth', // Basic authentication
// 'cache' => MODPATH.'cache', // Caching with multiple backends
// 'codebench' => MODPATH.'codebench', // Benchmarking tool
// 'database' => MODPATH.'database', // Database access
// 'image' => MODPATH.'image', // Image manipulation
// 'orm' => MODPATH.'orm', // Object Relationship Mapping
// 'unittest' => MODPATH.'unittest', // Unit testing
// 'userguide' => MODPATH.'userguide', // User guide and API documentation
));
モジュール（modules）とは？
標準で用意されているモジュールはクラスを中心としたUtil系のライブラリですが、モジュールはそれ1つをアプリケーションにする事が出来ます。modulesディレクトリの構成はapplication配下とほぼ同じになっていて、クラスはもちろん、コントローラやモデル、ビュー、コンフィグ、多言語化のファイルまで含む事が出来ます。
これは巷ではHMVCと呼ばれているらしく、機能毎にモジュール化しておく事で再利用性も高まりますし見通しも良くなります。例えば私は会員制のサイトで以下の3つのモジュールを作成しています。
- site
- manage
- account
siteはトップ画面や問い合わせ画面など、ログインしなくてもアクセス出来る画面を集めています。
manageはログイン後に利用する管理画面を集めています。
accountはアカウント登録画面やログイン画面などのユーザ情報に関わる部分を集めています。
このモジュール間を連動させることで、siteやmanage内のクラスは、accountモジュールからログイン情報を受け取るといった使い方をしています。manageとaccountを分離しておくことで、新たなアプリを作ったとしてもログイン系の機能はaccountモジュールに任せることが可能となり、テストや機能追加がやりやすくなります。
私の個人的な意見としては、application以下は利用せずに、全てモジュールとして作成することをおすすめします。
モジュールを利用する際の注意点
Kohanaではautoloadを利用してクラスを読み込んでいます。紹介 その2 クラスロードについて - isherの日記
modulesディレクトリの構成はapplication以下とほぼ同じと書きましたが、名前空間を利用しているわけではなく、安易な名前をつけるとクラス名が衝突してしまうことが良く有ります。優先順位はapplication > modules > systemとなっていて、modules内の衝突は先に書いた物が優先されるようです。
例えばapplicationにapplication/classes/class1.phpを作成し、mymoduleというモジュールを作成してそこにmodules/mymodule/classes/class1.phpを作成したとします。どちらもclasses直下となるのでクラス名はClass1となります。この場合はどこで利用したとしても、application配下のClass1が利用されることになります。
これは便利でもあり、気をつけないとハマってしまう点でもあります。バッドノウハウになりますが、classesの下にモジュール名でディレクトリを作成する等すればクラス名の衝突は避けられると思います。
