Laravel勉強会 2016

Transcript

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