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.
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! 👏🏽😄
I made an app in blazor server. If i display an invoice # 1 with detail rows and switch to invoice #2. then i if i go to DB back end and change Qty from 1 to 2 of Invoice #1 using update query. Now if i retrieve invoice #1 again in UI it still shows me old Qty and not Qty=2. Ever since I am using DBContextFactory this problem is gone.
What about using the Repository Pattern and UnitOfWork to handle the DbContext Instance and dispose of the DbContext after each operation as well, could it still work??
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?
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" @
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
In theory it works but you will still have to deal with other problems because even if you inject the DbContext into a service and then the service into the component, when the service is called by the component, both instances will be kept as long as the component is rendered (even if the DbContext and the service are Transient). This means that if you try to do an operation in the component and it fails in the DbContext, the error will still be in the ChangeTracker until that instance is disposed, but to disposed it you first have to dispose the service instance that is in the component, which basically boils down to having to reload the component or the page.
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.
![[#2024MAMA] ROSÉ (로제), Bruno Mars - APT. | Mnet 241122 방송](http://i.ytimg.com/vi/dgGqD28J6aQ/mqdefault.jpg)
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
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!
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.
Excelente gran problema que me has ahorrado. Si ya me estaba dando lata y no sabía cual era el problema.
I made an app in blazor server. If i display an invoice # 1 with detail rows and switch to invoice #2. then i if i go to DB back end and change Qty from 1 to 2 of Invoice #1 using update query. Now if i retrieve invoice #1 again in UI it still shows me old Qty and not Qty=2. Ever since I am using DBContextFactory this problem is gone.
What about using the Repository Pattern and UnitOfWork to handle the DbContext Instance and dispose of the DbContext after each operation as well, could it still work??
YES! finally thats what i was looking for the whole day.... noone says about it in examples or docs
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?
Is EF Core going to work with DbContext Factory without any modifications?
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 ?
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 :)
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!
Not clear how to solve the Dummy1 and Dummy2 problem though.
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.
In theory it works but you will still have to deal with other problems because even if you inject the DbContext into a service and then the service into the component, when the service is called by the component, both instances will be kept as long as the component is rendered (even if the DbContext and the service are Transient). This means that if you try to do an operation in the component and it fails in the DbContext, the error will still be in the ChangeTracker until that instance is disposed, but to disposed it you first have to dispose the service instance that is in the component, which basically boils down to having to reload the component or the page.
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.
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.
Nice vídeo!
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?
thank you
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.
Díky!
Thanks for the super!