はじめに
- フレームワークを直接継承して使わないで欲しいのでその警鐘
- 今回は例として
FuelPHPを使います - 使うと不都合がある一例なので直接継承した方が良いケースもあるかもしれません
問題のあるケース
-
FuelPHPを入れる -
userモデルをOrm\Modelを継承して作成
class Model_User extends Orm\Model{
}
-
companyモデルをOrm\Modelを継承して作成
class Model_Company extends Orm\Model{
}
-
userとcompanyに共通のメソッドを持たせたくなった（例えばクエリログを仕込むなど） - 親に持たせておけば今後増えるクラスにも自動で入るのでありがたいが親クラスはフレームワークなので触りたくない
- とはいえ
userとcompany両方に同一のメソッドを生やすのは二重管理になるし、今後クラスが増えた時に同一メソッドを書く必要がある - 詰んだ＼(^o^)／
要するに
フレームワークを直接継承すると中間層がなく、共通の親クラス＝フレームワークになってしまうので、共通処理を入れたくなった時に「フレームワークを修正する」という選択肢が出てきてしまう
なので必ずフレームワークと実際に使うクラスの間に中間の親クラスを設けるようにしましょう
この際中間クラスは空でも可です
空でも間に入っていることで後の拡張性が高いです
fuel/app/classes/model/
├── base.php
│ ├── company.php
│ └── user.php
経験則
これは個人的な意見ですが、DBを扱うモデルに関していえば更に以下のようにしておくと後々楽になるケースが多い気がします
fuel/app/classes/model/
├── base.php
│ ├── auth.php
│ │ ├── company.php
│ │ └── user.php
│ │
│ ├── master.php
│ │ ├── company_type.php
│ │ └── user_type.php
auth.phpはログインしている企業・ユーザのみがアクセスすることができるテーブルの親で、データのアクセスに必ずログイン中のuser_idやcompany_idを必須とするような親クラスです
こうしておくことで意図せず他社・他人のデータをアクセスできてしまうような穴を構造で防ぐことができます
master.phpはマスタデータを持つようなデータの親で、ログイン中の企業・ユーザーに関係なくアクセスできて良いようなデータに使います
例えば企業やユーザーのタイプや分類などのマスタが該当します
こうしておくことで例えばマスターデータをモデルではなく配列やjsonで返したい、1度データを取得したら2回目以降はキャッシュを参照したいなどのケースの時に親クラスに書けば済むようになります
おわりに
ORMは特に中間層は絶対に作っておきましょう
クエリの根っこの部分になるので差し込みたい処理がたくさん出てくるはずです
その他コントローラーの根っこ、プレゼンターの根っこなど、必要になってから作成でもいいですが空でも設置しておくと後々楽になります
今回はFuelPHPを例に取り上げましたが他のフレームワークでも理屈は同様なので、クラス設計する際には是非中間層の導入の検討を