DON'T Use DbContext In Blazor Interactive Server Components! (.NET8)
Вставка
- Опубліковано 7 чер 2024
- I see that there's a lot of confusion on how the new Blazor SSR and the interactive server render mode works under the hood. People are tempted to use the EF Core DbContext in interactive server components, but this will doom you to a future full of exceptions that will be hard to grasp and to fix. In this video I show you exactly how Blazor interactive server components work in .NET 8 and explain how their behavior might affect the DbContext and EF Core. Also I show how we can alternatively use IDbContext factory instead of the regular DbContext and explain why this is definitely a better idea.
#dotnet #blazor #efcore
Join this channel to get source code access and other perks:
/ @codewrinkles
CONTENT
1. Intro: 00:00
2. Understanding the setup: 00:49
3. InteractiveServer Render mode under the hood: 01:51
4. How this affect the DbContext: 06:46
5. IDbContextFactory to the rescue! 11:48 - Наука та технологія
First of all great video highlighting the DbContext issue in Blazor Server(.NET 6/7) and now in .NET for Interactive Server Side Rendering.
I encountered it back in .NET 6 and was able to resolve it back than using the technique you mentioned here.
I know it takes lot of time to create video and sharing it for the community, great work and great topic !.
I also noticed that every time we run EF query or any operation on EF we should always use await ... EF Operation, otherwise it can run into threading issue.
I'd think it's best practice to always use awaits when building user interfaces in general
Interesting video. I haven't used EFCore with Blazor so far, but I will keep it in mind for future projects. It's great to know. Thanks.
Thanks for watching and dropping a comment.
Thank you for your video! I found the solution to my issue with DbContext in Blazor Interactive Server. It worked perfectly with the solution from your video. I had no idea what could be causing the error in my application; it was functioning correctly until it suddenly stopped, throwing some very strange errors. I had no clue until I started searching online and happened to come across your video. Great help! 👏🏽😄
Glad it helped!
Nice vídeo!
Excelente gran problema que me has ahorrado. Si ya me estaba dando lata y no sabía cual era el problema.
If we do not use Ef and DBcontext, but perform our operations using system.data.sqlclient with a helper we wrote and dispose at the end of the transaction, will we encounter the same problem?
thank you
Would DbContextFactory work the same in Server/WASM/SSR - so we can use it in all types of Blazor Apps? Thx great video
Well, in wasm you cant't use ef core. You need to make API calls. For the others, yes, you can use the factory in both cases
@@Codewrinkles yes of course WASM needs to make an API 🙂 - so can the API itself use DbContextFactory so it's always consistent throughout ?
Díky!
Thanks for the super!
Nice, I've a Global InteractiveServer App which uses Repository Pattern and Services. I Inject IUserService in my Component and that Service use UnitOfWork that handles DbContext. I've faced exceptions while navigating to multiple components that uses DbContext.
Do you think If I just replace builder.Services.AddDbContext to AddDbContextFactory then it will resolve my issue?
When I switch b/w multiple components that use Services>DbContext I get this error: A second operation was started on this context instance before a previous operation completed. This is usually caused by different threads concurrently using the same instance of DbContext.
To me it seems like one of the problems that I described in the video.
I inject the service provider to my blazor components and manually create scopes in my components and get the services from these scopes. Are there any drawbacks with this? I don't like the idea of changing Backend code because some frontends behave different than others. The issue is not the Backend it's the frontend, so that's where I fix it.
That's definitely also a good approach and I like your reasoning.
Also just create a base component for your components and you have auto-scoping. That is what Blazor should have provide, auto scoping so that all the three render modes work the same.
I did the same thing last week on a project. Used a base component that would handle it's own scopes and resolve it's own services and just dispose them in the IDispose() of the component. I have a lot of existing backend services that rely on the DbContext being a Unit Of Work shared among services. And DbContextFactory wasn't going to provide the fix I needed. I'm curious how you implemented your "auto scoping"
@
Actually, I just did some more research and realized what I've implemented already exists:
OwningComponentBase. Much better that what I did :)
What about using Connection Pooling? Have you done a video on that?
I don't recall to have made a video on that topic.
@@CodewrinklesMight be worth it since the EfCore team seems to favor it over the others.
If I would have seen this video 3 years ago I would now have in total at least 1 week of my life back 🤣 btw I'm curious how do you handle repositories/services with this approach?
You inject the IDbContextFactory instead of the DbContext and than you do exactly what I didin the video. However, there is a certain level of awkwardness here (that I mentioned in the previous video) because your app will now have a lot of places where you can use the DbContext (regular SSR components) and a lof of places where you would need to use IDbContextFactory. That's in fact one of the major downsides of this new Blazor model.
That’s how I ended up doing it. I also find it a bit awkward, I was hoping someone has a more elegant solution. Maybe Microsoft will handle it in .Net 9 😁
Doesn't seem like that.Take a look at this Twitter thread. David Fowler doesn't seem to agree that there is a problem (maybe not problem, but very bad dev experience): twitter.com/danpdc/status/1724596015087357955
@@Codewrinkles Yeah, it seems we'll have to just be careful depending on the situation for now
What about using dbContext with ServiceLifetime.Transient ?
Yeah I run into concurrency issues. I registered the dbcontext as transient and it seems to work.
Is it efficient to create db context everytime?
Efficiency is the last of your worries if you don't.
@@Codewrinkles I am thinking to replace everything with factory, is it effective?
amazing video!
Is it possible to get the source code for this small project of yours :)
If you get into the Membership program on this channel at ambassador level, you'll always get the source code for each video.
I was having this trouble a few days ago. Wasted 5 hours to find out what was the problem...
I also learned this the hard way!