Laravel勉強会 2016

Transcript

1. エキスパートによる
   Laravel講座
   @株式会社イノベーション 2016/12/19
   

   View Slide

2. 株式会社イノベーション
   ではLaravel5.2を採用
   しております。
   

   View Slide

3. 正しく使えているかわからない問題
   

   View Slide

4. 独学では限界があるので、教えを請いたい
   

   View Slide

5. 講師をお招きしました
   

   View Slide

6. 竹澤 有貴さん
   1. 株式会社アイスタイル
   2. Laravelリファレンス著者
   3. 各地のPHPカンファレンス系イベントで
   よく喋ってます
   

   View Slide

7. 栗生 和明さん
   1. DIP株式会社
   2. リファレンス本レビュアー
   3. バージョン3のころから、趣味でLaravel
   使用
   

   View Slide

8. 弊社サービス紹
   介
   　Our Services
   https://www.innovation.co.jp/service/
   

   View Slide

9. ざっくり本日の
   テーマ
   First of all
   ● Laravelを使う上での原則
   ● 逆にアンチパターン
   ● その他、状況によるもの
   ● 個別のおはなし
   

   View Slide

10. Laravel原則とアンチパターン
    

    View Slide

11. 原則
    First of all
    ● DIコンテナ（Laravelそのものなの
    で）
    ● （原則というより）設計ありきで処
    理フローはお好きに
    ● あえて言うならオブジェクト指向
    設計の原則（と呼ばれるもの）に
    は従おう
    

    View Slide

12. アンチパターン
    Anti Pattern
    ● サービスロケーター
    ● コントローラーにDBアクセス処理
    を書く
    ≒ Eloquentのメソッドを使う
    

    View Slide

13. 状況に依るもの
    On a case by case basis
    ● Service Containerに登録する
    ルール
    抽象に依存しているケース
    Repositoryパターンや Service
    クラスやRequestクラスをまとめ
    るとか？）
    ● ServiceProviderを作る基準
    （分け方など）
    ● Facadeを使うルール
    

    View Slide

14. 個別に聞きたい
    localdiskさんの「Laravelにおける後悔しないため
    のアプリケーション設計」
    (https://speakerdeck.com/localdisk/laravelni
    okeruhou-hui-sinaitamefalseapurikesiyonshe-
    ji)
    のスライドをみて気になった点
    

    View Slide

15. 【理由】
    クラスの責務が大きくなる
    Facadeを使う代わりにDIにすると、メソッドの引数
    に使用するクラスが並ぶ（のがやばさを教えてくれ
    てよい）
    確かに・・・
    ではどのくらいまで？？
    ● 極端な話全てContractをDIすればよい
    か
    Facadeを控える
    責務を負いすぎていないかの目安を作る
    e.g. 依存関係で表したら10個もあるよ！
    ちゃんと分割できてないよ！
    

    View Slide

16. どうしても太りがちなControllerがすっきり ！
    php artisan make:request **** で作成できる
    ので、推奨ぽい
    Requestに対する操作やValidation処
    理が膨らむなら、有無を言わさず導入し
    たほうがよいか？
    いいと思う！
    FormRequest
    

    View Slide

17. 【なぜよくないか】
    Controllerの責務の問題
    Modelにクエリを閉じ込め、 ControllerはModelのメ
    ソッドを呼ぶのみ
    Model（らしきもの）でEloquentのメソッ
    ドチェインする分にはOK
    デメテルの法則的な話を含む
    徹底すべき
    ControllerでEloquentのメソッドチェイン禁止
    

    View Slide

18. 良さと、注意点を聞きたい（テストで困るのは分かるが、Repositoryパターンでなく
    てもサービス層を分離できそうな気がする）
    リポジトリパターン
    Laravel界隈のリポジトリパターンが間違っている情報も多い
    本家であるSymfonyのDoctrineのデータマッパーパターンを知る
    DDDについても知る
    

    View Slide

19. Conclusion
    まずは組織としての目指す方向性
    そしてフレームワークのソースコードから読み取る
    ドメイン駆動設計でやりたいなら、学ぶための良書がいくつかあるので、それを読む
    それ以前にオブジェクト指向の基本、「疎結合を守る」などシンプルな部分
    

    View Slide