I think controller and service layer is enough for most of the laravel applications. Hence we are re creating all the method in the repository which is already available in the laravel eloquent model, it seems like a repetitive work without any additional benefit. We can just keep our controller clean and pass the business login to service class , then resolve the function my accessing database via eloquent models and then return the result to controller. in that way we can use the laravel already build eloquent powers easily and quickly.
Please people, do not use a repository pattern in Laravel. Laravel has a beautiful active record solution and a repository pattern would only make sense when you would actually want to swap your database implementation, from let's say Mysql to Mongo for example. Do not use 'patterns' for the sake of using them. .
eloquent can switch over databases with some config changes in the database config and/or eloquent model. question is… is switching from sql to nosql or vv a thing?
Hello we made injection on BaseRepository for Model but ı did same things laravel give an error like " Target [Illuminate\Database\Eloquent\Model] is not instantiable while building [App\Http\Controllers\BlogController, App\Repositories\BlogRepository]" when ı make like " $this->app->bind(BlogRepositoryInterface::class,BlogRepository::class);" in AppServiceProvider for solition ı changed this as " $this->app->bind(BlogRepositoryInterface::class,function (){ return new BlogRepository(new Blog()); });" is there any solution ? Thank you for feeds from now ...
You have the freedom to change the implementation of the repository i.e you can change persistence layer or move it to a 3rd party without changing how it interacts with the rest of the application
Its better to use BlogPost::query()->toBase()->first() instead of BlogPost::first()->toArray(), because in second scenario, laravel convert array from DB to Eloquent, and convert eloquent to array. In first scenario you get raw data without converting
answer for this: Illuminate\Contracts\Container\BindingResolutionException Target [Illuminate\Database\Eloquent\Model] is not instantiable while building [App\Http\Controllers\BlogPostController, 00000000000000560000000000000000, App\Repositories\Repositories\BlogPostRepository]. ??
I never use it personally but some of the reasons include decoupling the entity model from the database or organisation and reuse of more complex queries
You can mock it easier for tests and it is cleaner imo. I like repositories for readonly eloquent/queries and services on top of that only if I need some more processing/logic + jobs if u need to update/insert/delete. Personally I think it is much better then throwing all to services.
Its better to use BlogPost::query()->toBase()->first() instead of BlogPost::first()->toArray(), because in second scenario, laravel convert array from DB to Eloquent, and convert eloquent to array. In first scenario you get raw data without converting
nice one to structure our code..hope for such more
I think controller and service layer is enough for most of the laravel applications. Hence we are re creating all the method in the repository which is already available in the laravel eloquent model, it seems like a repetitive work without any additional benefit.
We can just keep our controller clean and pass the business login to service class , then resolve the function my accessing database via eloquent models and then return the result to controller.
in that way we can use the laravel already build eloquent powers easily and quickly.
really nice video! you covered a lot of info! congrats for your work!
I think service (action) + DTO is better you may want to create a video on it
Please people, do not use a repository pattern in Laravel. Laravel has a beautiful active record solution and a repository pattern would only make sense when you would actually want to swap your database implementation, from let's say Mysql to Mongo for example. Do not use 'patterns' for the sake of using them. .
eloquent can switch over databases with some config changes in the database config and/or eloquent model.
question is… is switching from sql to nosql or vv a thing?
Hello we made injection on BaseRepository for Model but ı did same things laravel give an error like " Target [Illuminate\Database\Eloquent\Model] is not instantiable while building [App\Http\Controllers\BlogController, App\Repositories\BlogRepository]" when ı make like " $this->app->bind(BlogRepositoryInterface::class,BlogRepository::class);" in AppServiceProvider for solition ı changed this as "
$this->app->bind(BlogRepositoryInterface::class,function (){
return new BlogRepository(new Blog());
});" is there any solution ? Thank you for feeds from now ...
what are the advantages to implementing the BlogRepositoryInterface as to just injecting the BlogRepository directly in the constructor??
You have the freedom to change the implementation of the repository i.e you can change persistence layer or move it to a 3rd party without changing how it interacts with the rest of the application
Good Video!
great work
Hi!
I would suggest to use Route::resource
Never. I hate those! They decrease visibility for me
Its better to use BlogPost::query()->toBase()->first() instead of BlogPost::first()->toArray(), because in second scenario, laravel convert array from DB to Eloquent, and convert eloquent to array. In first scenario you get raw data without converting
Because this line is very long you can tell that this is an enterprise application... 😆
answer for this:
Illuminate\Contracts\Container\BindingResolutionException
Target [Illuminate\Database\Eloquent\Model] is not instantiable while building [App\Http\Controllers\BlogPostController, 00000000000000560000000000000000, App\Repositories\Repositories\BlogPostRepository]. ??
can u please give me a source code of this video to study?
I don't have source code for it unfortunately. Will be doing that for any videos going forward 😄
Why add an extra layer to Eloquent with interfaces and DTOs?
This approach only clutters the code and reduces its maintainability.
I never use it personally but some of the reasons include decoupling the entity model from the database or organisation and reuse of more complex queries
You can mock it easier for tests and it is cleaner imo. I like repositories for readonly eloquent/queries and services on top of that only if I need some more processing/logic + jobs if u need to update/insert/delete. Personally I think it is much better then throwing all to services.
I personally do
controller
Eloquent is a Repository . Don't use Repository Pattern if your Repository get data by Eloquent . it's meaningless
Thnx for approach guide. But could you not speed up the words partially within eat the volume at the end of phrase.. 😅
Its better to use BlogPost::query()->toBase()->first() instead of BlogPost::first()->toArray(), because in second scenario, laravel convert array from DB to Eloquent, and convert eloquent to array. In first scenario you get raw data without converting