エキスパートによるLaravel講座@株式会社イノベーション 2016/12/19
View Slide
株式会社イノベーションではLaravel5.2を採用しております。
正しく使えているかわからない問題
独学では限界があるので、教えを請いたい
講師をお招きしました
竹澤 有貴さん1. 株式会社アイスタイル2. Laravelリファレンス著者3. 各地のPHPカンファレンス系イベントでよく喋ってます
栗生 和明さん1. DIP株式会社2. リファレンス本レビュアー3. バージョン3のころから、趣味でLaravel使用
弊社サービス紹介 Our Serviceshttps://www.innovation.co.jp/service/
ざっくり本日のテーマFirst of all● Laravelを使う上での原則● 逆にアンチパターン● その他、状況によるもの● 個別のおはなし
Laravel原則とアンチパターン
原則First of all● DIコンテナ(Laravelそのものなので)● (原則というより)設計ありきで処理フローはお好きに● あえて言うならオブジェクト指向設計の原則(と呼ばれるもの)には従おう
アンチパターンAnti Pattern● サービスロケーター● コントローラーにDBアクセス処理を書く≒ Eloquentのメソッドを使う
状況に依るものOn a case by case basis● Service Containerに登録するルール抽象に依存しているケースRepositoryパターンや ServiceクラスやRequestクラスをまとめるとか?)● ServiceProviderを作る基準(分け方など)● Facadeを使うルール
個別に聞きたいlocaldiskさんの「Laravelにおける後悔しないためのアプリケーション設計」(https://speakerdeck.com/localdisk/laravelniokeruhou-hui-sinaitamefalseapurikesiyonshe-ji)のスライドをみて気になった点
【理由】クラスの責務が大きくなるFacadeを使う代わりにDIにすると、メソッドの引数に使用するクラスが並ぶ(のがやばさを教えてくれてよい)確かに・・・ではどのくらいまで??● 極端な話全てContractをDIすればよいかFacadeを控える責務を負いすぎていないかの目安を作るe.g. 依存関係で表したら10個もあるよ!ちゃんと分割できてないよ!
どうしても太りがちなControllerがすっきり !php artisan make:request **** で作成できるので、推奨ぽいRequestに対する操作やValidation処理が膨らむなら、有無を言わさず導入したほうがよいか?いいと思う!FormRequest
【なぜよくないか】Controllerの責務の問題Modelにクエリを閉じ込め、 ControllerはModelのメソッドを呼ぶのみModel(らしきもの)でEloquentのメソッドチェインする分にはOKデメテルの法則的な話を含む徹底すべきControllerでEloquentのメソッドチェイン禁止
良さと、注意点を聞きたい(テストで困るのは分かるが、Repositoryパターンでなくてもサービス層を分離できそうな気がする)リポジトリパターンLaravel界隈のリポジトリパターンが間違っている情報も多い本家であるSymfonyのDoctrineのデータマッパーパターンを知るDDDについても知る
Conclusionまずは組織としての目指す方向性そしてフレームワークのソースコードから読み取るドメイン駆動設計でやりたいなら、学ぶための良書がいくつかあるので、それを読むそれ以前にオブジェクト指向の基本、「疎結合を守る」などシンプルな部分