Laravel輪読会 ch3 アプリケーションアーキテクチャ
3-1 MVCとADR
3-1-1 MVC(Model View Controller)
@startuml class Controller class View class Model class Client Client --> Controller Controller --> Model Controller <-- Model Controller --> View Client <-- View @enduml
MVCとLaravel
Laravelにおけるコントローラ
MVCにおけるCの責務 | Laravelにおいて対応しているもの |
---|---|
HTTPリクエストの解釈(URI,HTTPメソッド) | routes/*.php |
制御を移すModel(ドメインロジック)の選択 | コントローラのメソッド |
表示するViewの選択 | コントローラのメソッド |
- リソースコントローラ
- CRUDのスキャフォールディング
Laravelにおけるモデル
- 「モデル」の本来の意味
- 小規模な場合はデータベース構造がそのままビジネス要求に結びつくこともある
- が、本質は別物
- いくつかの選択がある
- 【補】PoEAAのパターンとの対応
トランザクションスクリプトパターン
- 1つのビジネストランザクションを1つの手続きに紐付ける
- メリット
- 単純
- デメリット
- ビジネスロジックが複雑だと破綻する
- データの永続化にRow Data Gateway (≒LaravelにおけるEloquent)を使用している場合は、
ビジネスロジックをRow Data Gatewayに移植していくことで、推移的にActive Recordパターンになる
ドメインモデルパターン
- オブジェクトの相互作用でビジネスロジックを表現する
- メリット
- 複雑なビジネスロジックに対処できる
- オブジェクト指向の各種テクニックを適用できる
- 参考書籍
- Gang of Four
- Refactoring (Martin)
- if文減らせる、拡張性高い
- SOLID原則に撥ねる話
- O: オープンクローズド
- L: リスコフの置換原則
- I: インタフェース分離
- D: 依存性逆転
- 参考書籍
- オブジェクト指向の各種テクニックを適用できる
- 複雑なビジネスロジックに対処できる
- デメリット
- 難易度高い
- ビジネスロジックがシンプルな場合は大げさ
Laravelにおけるビュー
- Illuminate\Http\Responseクラス
- Illuminate\View\Viewは結局Responseインスタンスになる
3-1-2 ADR(Action Domain Responder)
@startuml class Action class Responder class Model class Client Client --> Action Action --> Model Action <-- Model Action --> Responder Client <-- Responder @enduml
アクション(Action)
- 単メソッドコントローラ
ドメイン(Domain)
- MVCのModelに同じ
レスポンダ(Responder)
3-2 アーキテクチャへの入口
3-2-1 フレームワークとアーキテクチャ設計
3-2-2 アーキテクチャ設計のポイント
3-2-3 レイヤードアーキテクチャ
- リポジトリパターンを実装してみようの巻
レイヤ化のための概念
- SOLIDのS
- 単一責任の原則
- 【補】それぞれの責務
3-2-4 レイヤードアーキテクチャの一歩先の世界
- 参考文献がいっぱい