Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Laravel勉強会 2016
Search
hihats
December 19, 2016
Technology
0
1.4k
Laravel勉強会 2016
hihats
December 19, 2016
Tweet
Share
More Decks by hihats
See All by hihats
Which Json Serializer should we use in Ruby on Rails6 era
hihats
1
120
ソフトウェア設計についての基本認識
hihats
1
82
アジャイル開発を始める前におさえておきたいこと
hihats
0
100
AWS Lambdaの今現在
hihats
0
790
コードの静的解析ツールを使う目的と効用
hihats
0
220
DIコンテナを学ぶ
hihats
2
390
Other Decks in Technology
See All in Technology
生成AIの活用パターンと継続的評価
asei
3
240
巨大企業でDX革新を起こすということ BTCONJP 2024
yamaken66
0
210
全社を巻き込んだ業務オペレーション改善と、それは事業成長に貢献しているのか?を実感した話
marroooon
0
130
Microsoft 365 でデータセキュリティを強化しよう
sophiakunii
2
470
SOLID - Architecture and Architectural Decisions - Devfest Goa 2024
rivuchk
0
160
Road to Single Activity Uncovered
yurihondo
0
110
さくっと実践!Postmanを活用した高品質で持続可能なAPI管理
yokawasa
5
360
フェンリルの SwiftUI の研修を覗いてみる / Fenrir SwiftUI Training
studio_rookery
0
150
エンジニア向け会社紹介資料
caddi_eng
14
270k
新入社員 オンボーディング改善プロジェクト - シンプルな仕組みで変革のきっかけを
enpipi
0
440
40代後半で開発エンジニアからクラウドインフラエンジニアにキャリアチェンジし、生き残れる自信がようやく持てた話
iwamot
9
8.1k
20241017_俺たちは雰囲気で scope をやっているけどもうちょっとなんとかならんのか?
tokai235
0
320
Featured
See All Featured
The Pragmatic Product Professional
lauravandoore
31
6.2k
Speed Design
sergeychernyshev
23
540
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
355
29k
Designing for humans not robots
tammielis
249
25k
The Cost Of JavaScript in 2023
addyosmani
43
5.9k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
664
120k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
22k
Optimizing for Happiness
mojombo
375
69k
10 Git Anti Patterns You Should be Aware of
lemiorhan
653
59k
Done Done
chrislema
181
16k
Unsuck your backbone
ammeep
668
57k
Thoughts on Productivity
jonyablonski
67
4.3k
Transcript
エキスパートによる Laravel講座 @株式会社イノベーション 2016/12/19
株式会社イノベーション ではLaravel5.2を採用 しております。
正しく使えているかわからない問題
独学では限界があるので、教えを請いたい
講師をお招きしました
竹澤 有貴さん 1. 株式会社アイスタイル 2. Laravelリファレンス著者 3. 各地のPHPカンファレンス系イベントで よく喋ってます
栗生 和明さん 1. DIP株式会社 2. リファレンス本レビュアー 3. バージョン3のころから、趣味でLaravel 使用
弊社サービス紹 介 Our Services https://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/laravelni okeruhou-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 まずは組織としての目指す方向性 そしてフレームワークのソースコードから読み取る ドメイン駆動設計でやりたいなら、学ぶための良書がいくつかあるので、それを読む それ以前にオブジェクト指向の基本、「疎結合を守る」などシンプルな部分