Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

講師をお招きしました

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

Laravel原則とアンチパターン

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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