Thank you all for watching and for your support. ►► If you want to master Web API development using best practices, check out our Web API book: bit.ly/3x75ZMM ►► Also, to build great full-stack apps with Blazor, check out our course: bit.ly/3Pw3Y33
Hi. I am sorry, but I don't have it for this one. Basically, I would have to share an entire project from our book package, which is not fair for those who already bought the book.
How about using the factory pattern to decouple the data persistence layer from the business logic? This would make it easier to switch the data persistence layer in the future.
Well, I never did something similar, and to be honest it sounds to me like a bit of overengineering. But again, this is only because I really never did that in my projects. That said, if it is to be considered as a best practice, I certanly wouldn't put it inside the Web API best prctices list becuse the Factory pattern is one of the best patterns (again in my opinin) and as a creational pattern, you can use it in any C# app. So, it would be more as a C# best practice.
Could you please share the reason why we shouldn't put any business logic in our controllers? I have learned to use your onion architecture repo example, but I take out the service layer and put business logic in the controller because I don't want my project to be too complex.
Hi. To make the explanation simple, the controller should be just a bridge between the client using your API and your API's logic. You can look at your controllers as proxies responsible only for the request itself. So it should accept the request, if that request has a body, we can do a validation (but as you can see, you can move that away from the controllers as well) and then simply forward that request to the service layer. It should know nothing about the business logic. Once the service layer returns a result, the controller should simply notify the client about that. This is just a simple separation of concerns. Each layer has its job and it should be doing it well. Finally, the code is cleaner because business logic can explode pretty quickly and then you have a lot of mess in your controllers. Will it work, yes of course, but just because you can do it doesn't mean you should. Anyway, we are all architects of our apps and if you think this fits your needs perfectly, you can do that, I just don't think it is the right thing to do. Having a service layer will not make your solution complex, just as opposite. It will make it cleaner.
At 9:56 and beyond you mentioned paging, filter, search, sort, etc. But I don't see such an implementation in your onion architecture repository. Do you cover that in another specific video/article? or is it only in your paid membership/content?
I have a Paging video recorded. A bit older, but I have it here. But the full implementation of all the API features, Paging, Sorting, Filtering, Searching, Auth, HATEOAS, Data Shaping, etc... is placed in our Web API book which you can find in the description.
Thank you too for the support. We have more than 5k people who purchased the book package and countles of great reviews, some of them were changing the job, some were applying for a new one, some just wanted to go over what they already know, but it prooved to be of great value to them. You can find some of the reviews on the sales page. Or take a look at the Gumroad's score mark.
Thank you. I don't have a source code for this one only, when we talk about new videos. This is more of a retrospective of what I consider to be the best practices and also all the examples you see are from our Web API book, so I can't just share the entire book's code.
@@CodeMaze thank you, your content made me buy the premium :) absolutely delighted with the content. Just wondering why you use different structures for the onion architecture that you propose. Even the names differ, sometimes you group the lower layer onto Entities and sometimes onto Domain.
Hi. Thanks a lot for the support. Sorry for a bit later response... time zone :) To be honest I don't understand what you mean by a "different structures". Our book's second edition source code (from the end of the book where everything is over) has the same organization as you can see in the video. You bought the second edition, so this should be the same. In the first edition there were some differences. That's why we created a second one with a lot of changes and improvenments.
Hi. There is no source code for this one as all the examples are part of the source code from our Web API book. Basically all the code from the video are just snippets from the full project from our book.
Thank you all for watching and for your support.
►► If you want to master Web API development using best practices, check out our Web API book: bit.ly/3x75ZMM
►► Also, to build great full-stack apps with Blazor, check out our course: bit.ly/3Pw3Y33
can i get this src code .i like that generic repository
Hi. I am sorry, but I don't have it for this one. Basically, I would have to share an entire project from our book package, which is not fair for those who already bought the book.
The video is informative. Concepts were clear.
Thank you. I'm glad you liked it.
How about using the factory pattern to decouple the data persistence layer from the business logic? This would make it easier to switch the data persistence layer in the future.
Well, I never did something similar, and to be honest it sounds to me like a bit of overengineering. But again, this is only because I really never did that in my projects. That said, if it is to be considered as a best practice, I certanly wouldn't put it inside the Web API best prctices list becuse the Factory pattern is one of the best patterns (again in my opinin) and as a creational pattern, you can use it in any C# app. So, it would be more as a C# best practice.
This video need more likes!
Thanks a lot. We will get there at some point :)
Could you please share the reason why we shouldn't put any business logic in our controllers? I have learned to use your onion architecture repo example, but I take out the service layer and put business logic in the controller because I don't want my project to be too complex.
Hi. To make the explanation simple, the controller should be just a bridge between the client using your API and your API's logic. You can look at your controllers as proxies responsible only for the request itself. So it should accept the request, if that request has a body, we can do a validation (but as you can see, you can move that away from the controllers as well) and then simply forward that request to the service layer. It should know nothing about the business logic. Once the service layer returns a result, the controller should simply notify the client about that. This is just a simple separation of concerns. Each layer has its job and it should be doing it well. Finally, the code is cleaner because business logic can explode pretty quickly and then you have a lot of mess in your controllers. Will it work, yes of course, but just because you can do it doesn't mean you should. Anyway, we are all architects of our apps and if you think this fits your needs perfectly, you can do that, I just don't think it is the right thing to do. Having a service layer will not make your solution complex, just as opposite. It will make it cleaner.
@@CodeMaze Well explained, thank you
You are most welcome.
At 9:56 and beyond you mentioned paging, filter, search, sort, etc. But I don't see such an implementation in your onion architecture repository. Do you cover that in another specific video/article? or is it only in your paid membership/content?
I have a Paging video recorded. A bit older, but I have it here. But the full implementation of all the API features, Paging, Sorting, Filtering, Searching, Auth, HATEOAS, Data Shaping, etc... is placed in our Web API book which you can find in the description.
@@CodeMaze Ok. I'll consider buying the course. I learned a lot from your resources, it's easy to follow. I think it fits me best. Thank you.
Thank you too for the support. We have more than 5k people who purchased the book package and countles of great reviews, some of them were changing the job, some were applying for a new one, some just wanted to go over what they already know, but it prooved to be of great value to them. You can find some of the reviews on the sales page. Or take a look at the Gumroad's score mark.
Great explanation. Link to the repo? I don't find it even even as your Patreon sponsor.
Thank you. I don't have a source code for this one only, when we talk about new videos. This is more of a retrospective of what I consider to be the best practices and also all the examples you see are from our Web API book, so I can't just share the entire book's code.
@@CodeMaze thank you, your content made me buy the premium :) absolutely delighted with the content. Just wondering why you use different structures for the onion architecture that you propose. Even the names differ, sometimes you group the lower layer onto Entities and sometimes onto Domain.
Hi. Thanks a lot for the support. Sorry for a bit later response... time zone :) To be honest I don't understand what you mean by a "different structures". Our book's second edition source code (from the end of the book where everything is over) has the same organization as you can see in the video. You bought the second edition, so this should be the same. In the first edition there were some differences. That's why we created a second one with a lot of changes and improvenments.
Thanks
You are most welcome.
Thank You
You're welcome
can you provide source code as well? thank you
Hi. There is no source code for this one as all the examples are part of the source code from our Web API book. Basically all the code from the video are just snippets from the full project from our book.
@@CodeMaze but where can i find this book?
Hi @@shkolnyy-maxym Please check the description of this video. It is the first link there stating Our Book.