Overview
The most often question I hear in Laravel is this: “Where should I put this code logic?”
Basic Laravel is an MVC framework, it’s clear what should be in Model, View, and Controller. But what if you have custom logic for processing data before passing it to the view? Where should it be?
- In the same Controller method?
- Function in the Model?
- Separate class, like Service? Or Action?
- Put as a Job into the Queue?
- Or, maybe, a global helper function without any class?
And the list goes on.
Of course, the correct answer is it depends. But depends on what? This is what I’m gonna talk about in this course.
The goal is to discuss practical examples of structuring larger Laravel applications, various approaches, and patterns. We will analyze existing popular open-source projects and their structure.
Notice: this course won’t be about design patterns. So fancy keywords like Singleton, Factory, Adapter etc will be used only when appropriate. What I will try to do is focus on the practical side: folders, classes, and methods, and not on how that pattern actually is called in theory. In reality, every project is actually a mix of patterns, and developers don’t even know what they’re called.
Episodes
-
Saving Data: Service or Action Class?
05:53
-
Repositories: Why NOT to Use Them?
04:16
-
"Background" Tasks: Dispatch Jobs into Queue
03:27
-
Dispatch an Event and Let Others Listen to it
05:31
-
Repeating Responses: Base Controller or Trait?
03:41
-
Global Helpers: Methods That "Don't Fit" Anywhere Else
02:59
-
Eloquent Mutators: 2 Open-Source Examples
03:41
-
Service Classes: 2 Open-Source Examples
03:40
-
Actions Classes: 2 Open-Source Examples
02:24
-
Jobs & Queues: 2 Open-Source Examples
03:46
-
Events & Listeners: 2 Open-Source Examples
04:02
-
Traits: 2 Open-Source Examples
02:19
-
Global Helpers: 2 Open-Source Examples
02:46
-
Structuring "Areas": Admin vs User - 3 Different Ways
07:10
-
Structuring Project into Modules with laravel-modules Pa.....
05:39
-
Packages: When Is It Worth Creating Them?
05:34
-
Domain Driven Design (DDD): Not Friendly with Laravel?
10:21
-
S: Single-Responsibility Principle - Too Big Methods
05:52
-
S: Single-Responsibility Principle - Too Big Controllers
04:10
-
O: Open-Closed Principle - Report Formats with New Cla....
05:03
-
O: Open-Closed Principle - Vendor in Laravel
02:48
-
O: Open-Closed Principle - Eloquent Attribute with Salary
04:04
-
L: Liskov Substitution Principle - Type-Hint Everything
05:21
-
I: Interface Segregation Principle - Default Laravel Models
03:21
-
I: Interface Segregation Principle - Separate Data and Dow....
02:52
-
D: Dependency Inversion Principle - Pass the Parameter a....
03:28
-
D: Dependency Inversion Principle - Report Interface
01:44
Intro
Moving Code Away From Controller
Practical Examples from Open-Source Projects
Architectural Structure: Areas, Modules, Domains
SOLID Code Structures
Reviews
No review yet.
Author
Povilas Korop
I've been creating PHP web-projects since 2001, last 5 years - with Laravel framework. Grew my freelance consultancy into a small team we call Laravel Daily.
Lately became more obsessed with customer success and business part of web, so practicing project management and entrepreneurship. Released our own product called QuickAdminPanel - code generator for the same Laravel framework.