This is honestly the most succinct, easy-to-understand explanation of SOLID principles of UA-cam. Don't be surprised if you review your analytics and find I'm responsible for half of the views on this video..😊
Regarding SRP, for example in Blazor, if i have a component with a form where users can either create a new item or edit an existing one, instead of having CreateItem() and EditItem() sitting on the component i should move them to a separated class which have an instance of the service that have the DbContext? Do i make an interface with these two methods or do i make a single one called for example PersistItem() and based on the data provided this class decide to either edit or create the item? (For example based on the fact that the Id is null or not). Then i can also make a separated class that get the data out from the db? This way you have queries and commands separated.
Yep, that’s the idea. Your blazor component would have a set of responsibilities but talking directly to a database should not be part of that. As for how to structure the database code I think those are all valid ways to do it. Your specific use cases should probably drive that choice, taking into consideration things like: - Are you persisting just one type or a graph of types? - Just a single object or hundreds? Maybe bulk inserts should affect the interface. - Will this info be used again very soon? Maybe it should be cached as well as persisted In general I think as long as you’re actually consciously thinking about it you’ll do well enough that if it needs to change it will be easier than if they were not separated.
Most of the time I will pick a single one to inject based on program arguments or the application settings. If you find yourself needing to decide which implementation you need at runtime it can sometimes be easier just to construct it at runtime since you know the type you want anyway. If that happens just get all your dependencies for constructing it via DI as normal
This is honestly the most succinct, easy-to-understand explanation of SOLID principles of UA-cam. Don't be surprised if you review your analytics and find I'm responsible for half of the views on this video..😊
Very simply explained. Shows you know your stuff
Sweet! Thanks for the video, I like the pace
awesome playlist 🔥
Thank you for the tutorial It was easy to understand..
Regarding SRP, for example in Blazor, if i have a component with a form where users can either create a new item or edit an existing one, instead of having CreateItem() and EditItem() sitting on the component i should move them to a separated class which have an instance of the service that have the DbContext? Do i make an interface with these two methods or do i make a single one called for example PersistItem() and based on the data provided this class decide to either edit or create the item? (For example based on the fact that the Id is null or not).
Then i can also make a separated class that get the data out from the db? This way you have queries and commands separated.
Yep, that’s the idea. Your blazor component would have a set of responsibilities but talking directly to a database should not be part of that. As for how to structure the database code I think those are all valid ways to do it. Your specific use cases should probably drive that choice, taking into consideration things like:
- Are you persisting just one type or a graph of types?
- Just a single object or hundreds? Maybe bulk inserts should affect the interface.
- Will this info be used again very soon? Maybe it should be cached as well as persisted
In general I think as long as you’re actually consciously thinking about it you’ll do well enough that if it needs to change it will be easier than if they were not separated.
@@tonydwire oh thanks a lot, you gave me more to think about!
In your Open close principle example, how would you inject the correct implementation now that they implement the same interface?
Most of the time I will pick a single one to inject based on program arguments or the application settings. If you find yourself needing to decide which implementation you need at runtime it can sometimes be easier just to construct it at runtime since you know the type you want anyway. If that happens just get all your dependencies for constructing it via DI as normal
@@tonydwire What I did was to create a factory that returned the correct type based on enum. But at the end I end up with another switch
What kind of IDE is that?
It’s neovim with some plugins to support c#, you can find more info here: ua-cam.com/video/qGl_Mb2C87c/v-deo.html