Laravel + Service Pattern + DTOs = ❤️❤️❤️

Hi guys!
In this video series, I'll be showcasing a simple way to integrate service pattern into existing Laravel applications. We'll start with a super simple example - an app that stores blog posts from the app and the api.
We'll do a couple of iterations before landing in type-safe service pattern solution that utilizes DTOs.
For more content visit saaslaravel.com

[@free2idol1]

11:15 using `tap()` to get the updated model instance after the update.
This is a great thing for me.
Thanks for fabulous video.

[@abdullah.alhabal]

yeah

[@kpomeru]

I had to take my time to understand this from the solution back to how it was implemented. This is insightful

[@peterpardo4138]

This is a GEM! Thank you so much for sharing this. I really appreciate you!

[@GayanSanjeewaKarunarathne]

This is just awesome. Good job mate! To be honest I think you covered more than just Services and DTOs. Keep it up 👍

[@sunnysk43]

Very very useful! Will definitely use it in my next project! Looks very promising.

[@SerG63rus]

One of the best videos which let’s you understand clever way to write code in just less than 20min.
Very very useful and pure.
Thank you!

[@VimKanzo]

I couldn't agree any better

[@unknownstalker2624]

Man, you are just awesome! Your content really helped me!

[@casweeney]

This video was really helpful, a lot of things now make sense. Thanks so much.

[@dongham2865]

I like this video. This is exactly the pattern I want. Thanks!

[@natenatters]

Great video! Thats very similar to how we are structuring our application. I like your approach of showing the iterations, a good way to learn. Thanks.

[@saaslaravel]

Thanks Natan! If you sprinkle some DDD on top it gets even better 🤓

[@e-raticartist]

huge improvement in the quality of my code after this, next level content

[@XTishka1980]

Amazing! Thank you for your lessons

[@zachariascreutznacher3093]

Very nice, simple and clean description about Services and DTOs in Laravel, thanks man 👍

[@soyarenamovediza6498]

Loved this video, thanks! You explained many patterns and did very well. I would like a video from yourself explaining some real life scenarios where these patterns really shine by themselves. I’ll share this video.

[@mayanksgajjar]

You just earned one more subscriber, thanks for sharing valuable information...😊

[@christiansosa5484]

Great stuff man! thanks for sharing

[@GonzaloGuevaraFreire]

Muy buen video. Muy entendible y progresivo.

[@mohammadravand4351]

thank you very mutch, this is very excelent video a bout laravel service pattern, 😍😍😍🥰

[@AhmadAli-jb6ri]

❤❤ Thanks for this tutorial...

[@chlouis-girardot]

Nice work ! Thanks for sharing 🙏

[@saaslaravel]

Thanks for watching!

[@lucasdepace]

Very cool! Thanks for the video
Keep making more videos please!

[@saaslaravel]

Thanks Lucas!

[@AdrianoAlves7]

I really do not understand why add complexity and more entities when we have some methods in Laravel to get all the validated data from a request. I like and i employ the Service Pattern because we can separate the app business logic from models and controllers, but the DTO.. oh my... i can't see any need for this. I would like to see a Video from you about Model Events and BroadCasting them. Thank you and congratulations for your great work, Przemyslaw. Greetings from Brazil.

[@saaslaravel]

Hi Adriano! Thanks for the kind words. Lemme explain the reasoning:
The biggest reason why DTOs are useful is it unifies the data passage through your application.
Let's say you have a piece of business logic that needs to be executed from your app, public api, command and a job. DTOs ensure that proper data gets passed to the service. Also, if you ever add a property, it will cause errors in places where it was not implemented / handled which also prevents bugs

[@felipeflashmaster]

So using the Model itself as a DTO would be the same, right? or how in typescript to use an interface

[@irlnidallah]

@@felipeflashmaster using the Model as a DTO itself would clutter the Model into a mess, if you're planning to implement DRY, that would not be a recommended approach.

[@abdurashid_dev]

Helpful content! Thank u!

[@saaslaravel]

You're welcome!

[@MrSfinks13]

Cool! Thank you!

[@SeyedaMansour]

wow, this was great

[@brunofunnie]

B-e-a-u-tiful!

[@user-dk4or7bs2q]

So nice

[@laxman123in]

Awesome

[@antonsobchuk7690]

Great job, man. What’s the theme of phpstorm you are using btw?

[@gazorbpazorbian]

awesome video dude! saw it again :D

[@saaslaravel]

Legend!

[@codewithtee]

This is good. Simple and easy to understand...
I have always wanted somethinh simple for dto instead of a package...
Will be improving some project with this implementation

[@saaslaravel]

Thanks! Glad you enjoyed it and good luck on your project

[@codewithtee]

While refatoring, I wonder how you would handle Request for update that has fields set as sometimes for validation. Considering for patch request, not all fields will be supplied.

[@saaslaravel]

@@codewithtee Often times I just duplicate the request, I like this approach because it's the most flexible one. You could try and extract common rules but as the resource gets more complex I think it just adds unnecessary complexity in something that should be sime. Another solution is to simply check the method in the request and modify the rules array but I find it harder to read :)

[@toheebabiodun70]

same here too..

[@borakayalar]

Perfect

[@midclock]

Nice tutorial!
You can check ide-helper to generate model auto completion for properties.
For dtos I find laravel-data by spatie a very good solution.
Cheers

[@saaslaravel]

Yeah I use both of them in my workflow! Def worth checking out for anybody interested though!

[@chris11651]

very informative, thank you very much!
what theme do you use in your IDE?

[@saaslaravel]

Thank you! It's called Catpuccino Mocha

[@gazorbpazorbian]

this is a very cool video.. nicely explained. what about making a video about php types?

[@saaslaravel]

Thanks so much! Types as in strings, ints etc? What would you like to know about them?

[@gazorbpazorbian]

@@saaslaravel everything hehe, like using a separated file, best practices, how to use it in a function like boot(): void and all that stuff.

[@NoNameUkr]

I prefer to pass array into static DTO method, then Request, for me its much safety, u can use this DTO from wherever u want, not only from Controller. Example: tomorow u will need to create Post from console command or from Job

[@saaslaravel]

Which you can still do by instantiating the DTO from the constructor. Imo array passing loses all of the benefits of type checking built into the class

[@bakre_dev8728]

Cool

[@artemkanarskyi8231]

Thanks is very helpful! I want ask as how use DTO when you have relations for example Post has many Comments. In PostDTO comments will be array/collections of CommentsDTO or simple array of ids?

[@saaslaravel]

Thanks Artem! It really depends on the scenario, I think there is a use-case for both
Option A: Nested models created all at once.
Example: You create BlogPost and it has different "sections" of content, or you create a Recipe that has Ingredients
Solution: In this example you'd have a RecipeDTO that has all of the recipe properties, and either an array of IngrednetDTO, or a IngredientDtoCollection (the latter if you want something that's more type-safe)
Option B: Creating a new model and associating it with existing ones
Example: You select which users should have access to a project
Solution: In this example you'd have a ProjectDTO, that'd contain an array with IDs of users to associate and then simply attach it to a pivot table
Lemme know if this makes sense!

[@artemkanarskyi8231]

@@saaslaravel Thank you for your help.

[@LowVi]

Really good man!
I would like to know what you think about adding an extra layer: the repository.
Because thats kinda whats going on my in job rn, laravel + service pattern + dto + repository,
I feel like the Model itself could act as the Repository, what do you think?

[@saaslaravel]

It really depends on what you are looking for from the solution. I'd say - if you don't have a good reason to introduce a repository - don't do it. If you want to have more fine grained control over your persistence layer (i.e to handle CQRS more easily) go for repository!

[@JSONFX]

What font are you using on this video? Thanks!

[@chenten420]

This is a really great video! Is there a repository where I can check the code for this example? I would greatly appreciate it.

[@saaslaravel]

I don't have it unfortunately but will probably start doing it going forward

[@Pavelbrov]

5:50 - what about duplication in BlogPostRequest validation for api and app? Can we get rid of it?

[@nicolascanala9940]

Hey! How do you approach having different validation rules in the store and update actions? For example, a StoreBlogRequest which marks all fields as required, VS an UpdateBlogRequest which doesn't (for example, you just wanna update the name). Would you create more than one DTO and mark the properties as nullable?

[@saaslaravel]

Hey there! It depends on the situation, generally speaking with updates I'd not go with nulls because partial updates are pretty sexy - if you use spatie/laravel-data - they handle it out of the box with Optional type hint

[@huntwithmeid]

Well done bro! Great videos. But I have a question here, so what is the benefit of using DTOs? I'm interested to use this in my project, is it hard to implemented in existing project. I'm also using service class.

[@saaslaravel]

The main benefit is making sure that the data you're passing is valid data that service can consume. This is especially useful when you have multiple pieces of app - console, public api and internal api calling the same service. You can just start implementing it on new services and then gradually go over existing code! Hope that helps :)

[@pwcodigo]

@@saaslaravel Obrigado !

[@GonzaloGuevaraFreire]

Además que simplifica el constructor

[@zulfikarditya7142]

Very nice tutorial. But i have a question, how to use DTO in many relational data like transaction with many items or something?. and we'll be use service as well,

[@saaslaravel]

It really depends on the usecase so it's hard to give you a good response here but you can also nest them and utilize arrays with phpdoc type hinting to skip some of the type limitations of php

[@VipStudio]

When you have form request class included into ur method you dont need to do $request->validated cuz the data is already validated otherwise it throws validate exception until first line of code starts compile from function

[@VipStudio]

And you dont need to use Dto u can just do create($request) //already validated clean data

[@Pavelbrov]

Is "laravel-data" package from spatie doing something similar?

[@saaslaravel]

Yes, it's just a concept that you need to know from scratch. Just a regular, plan, old PHP class. Nothing wrong with using the package!

[@iqbalrafli2191]

Good video, but i have a questions. What if we want to store data to two or more table from one endpoint controller?

[@saaslaravel]

You can include all data into one dto or pass two separate DTOs. It will depend on the usecase

[@lassestube]

You don’t need constructor, you can bind service in controller method automatically...

[@saaslaravel]

That's true, but I prefer using constructor. The method tends to have 2/3/4 arguments - with type hints it takes a lot of space, and when it lives on constructor level I can just define it once :D

[@lassestube]

@@saaslaravel makes sense as well :) I tend to use actions in method binding and if I use a service in more than one method I would promote it to the constructor.

[@mihaes7172]

I don't understand why instantiating a readonly DTO just to pass request vars to a writing service method? what's the 'secret' between request vars and service update method that dto needs to exists inside same controller method, concerning the same Post model? what if there are 25->50 controllers & models in the application? that would generate a lot of fancy classes, code to be reviewed, etc.
Sometimes we go overboard for the sake of buzzwords....

[@Pavelbrov]

17:20 - Shouldn't our DTO have a method like toArray so that we can manually avoid passing all the parameters? I mean, they correspond to the properties of the model. Or is this a bad practice?
Like this
public function toArray(): array
{
$properties = get_object_vars($this);
$array = [];
foreach ($properties as $key => $value) {
$snakeCaseKey = Str::snake($key);
$array[$snakeCaseKey] = $value;
}
return $array;
}
and then BlogPost::create($dto->toArray());

[@saaslaravel]

I prefer to be explicit when possible, realistically, just use spatie/laravel-data which handles this out of the box

[@3dxspx703]

Yikes. Model mutators and observers will be enough guys. But if you want to Over-engineer your code, then go on with dto or something like repository pattern. 😅

[@saaslaravel]

Until your app had 1200 endpoints and some places haven't been touched for years - yeah

[@3dxspx703]

@@saaslaravel yeah? But I prefer laravel's defaults for easier maintenance and debugging. Also KISS. Pfft

[@LucasOliveira-ny6kw]

.

[@deecee2204]

Why is this so painful to watch? no offense

[@saaslaravel]

Idk, why is it bud?

[@zayedadel8552]

million times better and understandable than any indian out there that i cannot understand

[@MrSfinks13]

Thank you! Very useful video, realy!