There is a sequel to this video showing how to use IDbContextFactory in reposityro/service based approach and in a CQRS based approach: kzread.info/dash/bejne/nn1t0bGApbvHgbw.html

Subbed. Clear and very well explained. I am just about the start a new project using EF with Blazor Server for the first time and most certainly I would never have thought of this issue until I would have been forced to learn it the hard way. Now, when explained it seems so obvious why a scoped DbContext makes no sense in Blazor Server. Thank you for saving me many hours of frustration down the road.

Thank you for this video. This was very helpful in understanding the difference between dbContext and dbContextFactory. Much appreciated.

Quick tip, starting with C# 8.0 you can use a using declaration instead of a statement with curly braces. E.g. using var reader = new StringReader(manyLines);

Thank you so much for this video! Its saved me so much time and I have taken away loads from it. Looking forward to watching many more videos from you. All the best from the UK.

This was super helpful thank you - A good practical demonstration of the pattern found in the docs. Subbed 🙌

@Codewrinkles

3 жыл бұрын

Awesome, thank you!

Best explanation on the internet regarding this topic. Subscribed. Thank you so much!

Sir I loved all of your rich content; it's real! I you may would you please never use background classical sound!!. It's very distructive for the course. I love to attain your course with full concentration. It's my opinion. You're my only extremely valuable mentor. Love you!!!

@Codewrinkles

Жыл бұрын

Ok thank you

Thank you very much. Your video really helped me to understand the concept of Blazor Server and Entity Framework Core. Before I saw your video, I was not aware with Blazor Server the frontend communicates with the backend through Web Socket (SignalR) and not HTTP request/response. Also the concept by using DbContextFactory is very important if you implement application with Blazor Server.

@Codewrinkles

Жыл бұрын

Glad it helped!

Good video, another approach mainly if you're abstracting your application in more layers is to use the ServiceScopeFactory, so you will be able to create a scope and then resolve everything inside this using the GetRequiredService

@Codewrinkles

3 жыл бұрын

I totally agree with you regarding to the ServiceScopeFactory service!

@richardaubin1951

Жыл бұрын

@@Codewrinkles maybe a follow up video with how to implement it? There's no content on youtube for that yet.

@Codewrinkles

Жыл бұрын

@@richardaubin1951 How to implement what? I have already plenty of videos on Blazor Server with EF Core and also plenty of videos on Blazor Server Authentication.

@richardaubin1951

Жыл бұрын

@@Codewrinkles Specifically giving an example of using IServiceScopeFactory as an additional method of getting DbContext to play nice with blazor server, if of course it is a viable solution.

Really solid video on the basics of using EF with Blazor Server. Understanding how contexts work is much better with examples on how it is used differently like this. I have a bit of a challenge that might push this a lot if you are interested. I am implementing a multi-app domain environment that is using a separate class library for the data access / domain components layer using ef core 6. I have defined the context in the class library and can create a dbfactory in the Blazor Server UI layer referencing that context (exactly like your example). I can also use the Blazor factory, in the class library classes to get a temp dbcontext using the method you showed above. However, this all seems like a leaky abstraction with the data access class library depending on the UI layer's factory service implementation. I guess it works, but is there a way for the class library methods to create a dbcontext that that has a unit of work scoped just to themselves without relying on the UI apps services? I hope I am explaining that well. I can have each app / UI that uses the DA layer inject a service, but again this seems wrong (but fine with doing it if that is the best / easiest way).

@Codewrinkles

2 жыл бұрын

I think I partially understand your point, but from my point of view your DAL libraries do not depend at all on the UI layer. The fact that you are registering your services in the UI layer, it doesn't mean that they depend on it. In fact, your DAL libraries don't have and dependency on the Blazor library. If you use tools to create a dependency graph, you'll see that your DAL libraries don't depend on anything except on the domain libraries. If you want however to create unit of work wrappers you can do that. Maybe have like a unit of work interface (IUnitOfWork) and an implementation, both in the Dal layer. In the implementation you then inject a DbContextFactory and take control there about everything. In your Blazor components you're then injecting you unit of works. Most of the thing mentioned in this video still apply, however. You should make sure that within your unit of work you create a new context when you need to perform an action and dispose it immediately afterwards. Last but not least, if the application is that complex, I'd go for a different architecture where I'd use CQRS. My components would then simply create a command or query and send it via a mediator to handler. Then in the handler I'd inject the unit of works that I need.

@chadbennett

2 жыл бұрын

@@Codewrinkles - THANK YOU for your reply. It really means a ton that you are helping others like this. Since the factory is created at the UI level and has knowledge of both EF and the database being used, and the DAL has to use that factory to create a context, doesn't that kind of mean the DAL is dependent on the UI/App layer? This may just be academic and may not really matter, but I'm curious your thoughts. I have been debating whether to use mediator and am thinking of a hybrid CQRS implementation currently. I like the idea of using a pattern that has read DA code directly in the UI layer (like you did above), but this completely breaks the separation model. The factory is already implemented at the UI level, and I am guessing it will be much easier to code/maintain without writing interfaces and implementations for those (will do a generic find all and byID at the DA though and try to use that mostly). For CUD I would use domain repositories. Would like to do reads there too if I could maintain the unit of work for the object being updated - guessing not though. This is a total hybrid and just my best guess at how to mix the pure academic "the right way to separate layers" vs what is easiest to code and maintain. I am the only developer for this and the overall apps/domain object usage is really small. Trying to not use mediator only to simplify my code / development. I will have multiple apps though that need to use the domain/DAL objects, so breaking them out in to a class library seems like the right way to go there. Sorry, its been a ton of researching this, with most results being how to do a function or the theory behind an architecture, but few if any on how to specifically architect this stack with a realistic DDD approach. Thank you again for your help.

@Codewrinkles

2 жыл бұрын

@@chadbennett Regarding the first paragraph, I would say NO, I can't see a dependency there. The factory is part of EF Core and essentially it is part of the DAL. Your Blazor app depends on the DAL as you are using that factory. But your repositories using the factory means that the repositories are using a functionality (DbContextFactory ) from within the same layer. IDbContextFactory is part of EF, not a part of Blazor.

Fantastically useful! Thank you very much!!!

Your channel is def underrated. I appreciate your in depth discussion. Quick question. You mention that using a scoped DbContext is not thread safe and can cause problems. What sort of problems does it create? Thanks in advance.

@Codewrinkles

Жыл бұрын

I guess you got me a little bit wrong. So, the general theory is exactly that DbContexts SHOULD BE SCOPED. This is thread safe and the way to go when you are using regular ASP.NET Core apps. The caveat is with Blazor Server. Because in Blazor Server, scoped means the LIFETIME OF THE CIRCUIT, which can be long lived. In regular apps, scoped means relative to the request, which is short lived. That's why we need to use IDbContextFactory in Blazor Server so that we can create an instance of the DbContext that is shortlived, scoped only to the specific operation that we want to perform in that moment. Regarding the channel, thanks to people like you it is constantly growing, And you can definitely help the growth by sharing the content that you find useful, by subscribing and/or by commenting on videos (which you already did :) ). Thank you once again for taking your time to watch the video and write a comment.

@ElCidPhysics90

Жыл бұрын

@@Codewrinkles Thank you. New to Blazor and the use of async/await... Quick question: which css framework are you using to style the date input?

@Codewrinkles

Жыл бұрын

@@ElCidPhysics90 Unfortunately, I am for sure not the right person to ask this :)

Thank you for the helpful tutorial! Is there any performance loss using this technique in comparison to the regular using of dbcontext? Thanks in advice.

@Codewrinkles

3 жыл бұрын

Actually not. On the other side, when it comes to Blazor there's NO regular way of using the dbContext. I explained in the video why this is the case.

This is fantastic. Thank you!

Thank you so much sir! Excellent and very valuable information about DbContextFactory and how important it actually is. But what about Dapper where we use SQL language directly and have no DbContext at all? Do you have videos about it?

Dear Dan Pătraşcu Baba , I hope this message finds you well. Firstly, I would like to thank you for sharing such valuable information. I highly appreciate it. Regarding your recommendation to use DbContextFactory in Blazor Server to handle potential issues with multiple components accessing the same instance of the db context, I wanted to clarify my situation. In my case, I am not directly writing any code in components to access the db context. Instead, I have created APIs in my controllers to handle CRUD operations. Additionally, my API controllers utilize a unit of work pattern, which means I am only using a normal DbContext for my unit of work. My question is, does this mean that all the endpoints in different controllers will receive the same instance from the unit of work? I am unsure if this approach is correct or if it could lead to any problems. I am wondering if placing the data access code in the controllers would solve this issue, in case using DBContextFactory is not necessary. I would greatly appreciate your guidance and clarification on this matter. Thank you once again for your expertise and support. Best regards, Waleed Bensumaidea

This video is GOLD. Thank you so much!

@Codewrinkles

2 жыл бұрын

Glad it was helpful!

@leob1945

2 жыл бұрын

@@Codewrinkles I'm watching now the video about n : n relationship with IDbContextFactory. Very good too!

In case of using a unit of work factory inside using would we need a dbcontextfactory to initialize our context ?

Also add try catch finally block in the end of Delete task (after using block), or page will not refresh after you will delete data.

Subbed, this video helped a lo

Thank you very much for your very usefull video. It is very clear. I have one question. I have an aggregate, named Order, with List into it. In every OrderLine i need to make a link with a User entity that is already exist in the database. When i create a new order, with 2 lines with the link to the same User, i have the following error, The instance of entity type 'User' cannot be tracked because another instance with the key value '{Id: 1}' is already being tracked. When attaching existing entities, ensure that only one entity instance with a given key value is attached. I don't know how to solve. Any idea ?

Good Video. Thank you :)

Thank you great video Sir

Good video, is there a way to use the lazy-loading with DbContextFactory because when im using it, it said that An attempt was made to lazy-load navigation "x" after the associated DbContext was disposed.

Really love your tutorials! Could you please segment your videos?

@Codewrinkles

Жыл бұрын

Most of the newer videos are segmented. I will also add chapters to this one.

Appreciate the video... just to aid your future videos "Circuit" is pronounced SER KIT the U is silent. Gotta love English!! :)

@Codewrinkles

8 ай бұрын

Thanks for the tip!

Thank you for valuable information, my question is how to add a login system to such a project? so that non-logged in users cannot access the database context.

@Codewrinkles

3 жыл бұрын

The idea of login is also different. We'll do a video about it the coming days. In short, for logging in, you would need a Razor page, not a Blazor component. The reason is that you want to set an authentication cookie and you can't do this from Blazor directly. In Blazor WebAssembly it's different again. You'd need to implement an OIDC flow for logging in (you'll probably also need an API backend for that or an Identity provider).

3 жыл бұрын

You can scaffold Identity in Blazor VS

Great Video ... is the code on Git?

I'm lost. Some of the pages aren't in my project. Where is WeatherDbContext defined in the project? I only see an ApplicationDbContext and it's mostly empty. Should there be a different DbContext for different models?

@Codewrinkles

3 жыл бұрын

I'm not sure what project you are using. Each project is different. The WeatherDbContext is not part of the Visual Studio Blazor Server template. I have added it manually before the video, as showing how to create a dbContext was outside the scope of this video. If you want to get started with EF Core and the dbContext please watch this video: kzread.info/dash/bejne/dYt23MaRcZTbgNo.html

@jaym9846

3 жыл бұрын

@@Codewrinkles > kzread.info/dash/bejne/dYt23MaRcZTbgNo.html Thanks for link. Yup, I needed to start with a more basic foundation first.

@Codewrinkles

2 жыл бұрын

Here's also a new video on this scenario: kzread.info/dash/bejne/nn1t0bGApbvHgbw.html

Couple questions, when adding the factory to the middleware (services.AddDBContextFactory) you did not remove the adding of the non-factory context (service.AddDBContext). Is it necessary to have both? Would having both cause issues with the db context being loaded multiple times and possible conflicts? Is the context factory basically syntactically similar to the context with the main difference being the instance lifetime? Also when deleting after the saveChanges to complete the delete operation would you not just reload the array similar to the initialization overload? Once the array is reloaded from the database the page would automatically display the list without the deleted record. Thank you for the detailed video.

@Codewrinkles

2 жыл бұрын

To avoid problems I usually advise to use both, however use them properly: 1. Regular DbContext in controllers or Razor pages (for authentication for instance) 2. The DbContextFactory in the Blazor part.

@1eagleusa

2 жыл бұрын

@@Codewrinkles Thank you

Thank you. Well done 👍

@Codewrinkles

Жыл бұрын

Thank you too!

I am wondering about using the Transient for the DBContext lifetime issue in Blazor server. Can you explain why this is a better solution?

@MrTJadam

2 жыл бұрын

I am wondering the same

@steviepca

Жыл бұрын

Transient results in a new instance per request; but as components can be long-lived, this results in a longer-lived context than may be intended. hovermind.com/blazor/recommended-approach-for-dbcontext-in-blazor-server.html

very usefull!

Any way to do this WITHOUT Entity Framework? (or ANY ORM, for that matter)

@Codewrinkles

2 жыл бұрын

Of course, you can use a SqlClient and take care about everything. I'm not sure about the added value of programming again the way we did program 15-20 years ago. I mean, you have a lot of choices when it comes to ORM: EfCore, NHibernate, or even lightweight tools like Dapper.

I have a few questions about this implementation: - Do you need a DbContext for every model in your program? Or can you use just the standard ApplicationDbContext? - What about the services layer? Because you invoke the CRUD operations with the dbcontext but what if you have other logic you want to use, how do you approach that? - You say that it is a good practice to implement the DataLoading for each operation (around 29:20). But don't you think it is kind of strange that you need al that code for just a CRUD operation? If I need to this for other CRUD operations in the same component file the lines of code will increase drastically. Thanks in advance!

@Codewrinkles

2 жыл бұрын

Thank you for your questions. I'll take them one by one. 1. We are actually using the same dbContext class, but the main thing is that we create a new instance of it every time we need it and make sure it is disposed at the end. It's a very standard approach for desktop apps development. And Blazor server is very similar in a certain way with the desktop model, as the component lifetiimes might be very long. As per the EF Core documentation, the context is not thread safe and could potentially cause a lot of problems if you use the same object in different places. In regular ASP.Net Core, we don't have this problem, as in that case, a new dbContext is created for each request. - You could definitely use a service layer. But if you use services in your Blazor server app, make sure to inject the DbContextFactory in them and create new instances each time you need them inthe service methods. Also make sure to implement IDisposable. - the Data loading part is actually more for UX. As your data loads, components will display missing data and it will look weird. Based on the DataLoading property you can show a loading screen untill the component is fully loaded. Hope that helped to clarify your doubts. If not, let's keep the discussion open.

@Codewrinkles

2 жыл бұрын

Also, regarding point two, I'd probably go with a CQRS approach and not use a service layer at all.

@jameskarsten5617

2 жыл бұрын

@@Codewrinkles Thanks for your answers!

@jameskarsten5617

2 жыл бұрын

@@Codewrinkles Hi Codewrinkles. I struggle a bit with the usage of services using the DbContextFactory and the IDisposable. Do you maybe have an example for this implementation? Thanks in advance.

@Codewrinkles

2 жыл бұрын

@@jameskarsten5617 Here is an example of a service constructor: private readonly IDbContextFactory _contextFactory; private readonly IMailSender _mailSender; public ProposalProcessingService(IDbContextFactory contextFactory, IMailSender mailSender) { _contextFactory = contextFactory; _mailSender = mailSender; } Here's a service method that uses the factory: public async Task ProcessProposalsForEmailSendingAsync() { List eligibleProposals = new List(); using (var context = _contextFactory.CreateDbContext()) { var proposals = await context.Proposals .Include(prop => prop.TargetedPoliticians) .ThenInclude(pol => pol.User) .Include(prop => prop.User) .ToListAsync(); eligibleProposals = proposals.Where(p => p.UpVotesCount > 10).ToList(); } await SendEmails(eligibleProposals); } Here, when we create the dbcontext instance, we put it in a using statement, so the dbcontext will be disposed when the work is done. You can inject the service in your Blazor components without any issues using this setup.

Your video is for the experienced candidates

@Codewrinkles

3 жыл бұрын

This one, yes, I would say it's target for mid-level developers. Feel free to search around the playlists, as I have playlists dedicated for beginners.

how about transactions, say I edit object 1 and you edit object 1 and our updates collide or a depending service fails like with card processing and order processing...

@Codewrinkles

2 жыл бұрын

That really depends on the use cases and exact scenarios that you want to implement. A common theme I have used in some real mid-sized applications and following a traditional layered architecture is the following: 1. Say we have a OrderProcessingService 2. In the order processing service we inject DbContextFactory an instantiate a new DbContext in each service method. 3. Inject other services here as well: CardProcessingService, ShipmentService 4. Inject the service in the components where you need it 5. In the service start and transaction and do whatever you want, then commit the transaction and return a response to the component. 6. Implement IDisposable in OrderProcessingService and add it as Transient to the DI container. That's one way to do it. You could also use an event driven approach. In more complex applications you may want to decouple the services. For instance, an order should be place even if the CardProcessingService fails. Order placement shouldn't care about that. Might even use different microservices for all of them. In the UI maybe ask the user to redo the payment and not ship the order until the payment is done. There are many possible ways and I don't see a major problem here.

@michaelwright2369

2 жыл бұрын

Really great tutorial which helped me understand how EF Core handles and disposes “units of work”.

I found out the hard way that Blazor was different when it comes to dbContext. Built a Blazor server app and had it all set up where components get updated from parameter changes. Well should have been updated in theory (the old way) but it didn't because when I updated the database and had the app check for an update it was just seeing the context data (old data) and not actually pulling from the dbase when it made those calls. I really thought that calling to the dbase would actually get the real data but that isn't true it will default to what is already stored in context after the first time context gets loaded. Mentioned in this video around 5:40 Tried a bunch of things like Reload() and new dbase instance but always ran into threading errors. So here I am, hoping I can get a better solution. lol.

@Codewrinkles

2 жыл бұрын

Thank you very much for you sharing your story. I guess it might be very useful to everybody that lands here in the future.

So, in case i want to reuse the methods (like Creation of Forecasts) that should be inside a service shouldnt it.

@Codewrinkles

2 жыл бұрын

Yes. you can definitely have a service that would do that. You could even have repositories that get a DbCOntextFactory and create a new instance of the DbContext each time a repository method is called and disposes it when the job is done. You can go a full layered approach and also inject the repository in a service class if you need to perform more complex logic. But you can even go the CQRS approach with mediatR. In that case you need to inject the DbContextFactory in the handler, get a new instance of DbContext, do the job and then dispose it. The important part is to always use the DbContextFactory when you work with Blazor Server.

@Codewrinkles

2 жыл бұрын

Here's a new video for this scenario + CQRS if interested: kzread.info/dash/bejne/nn1t0bGApbvHgbw.html

Subbing! 👍

@Codewrinkles

3 жыл бұрын

Thanks

this makes no sense to me. When updating a record - we load it using one context (which is quickly disposed via a 'using'), and then update the it using a different context - surely that doesn't make sense? I'm new to Core, but in .Net Framework the whole point of the context is to keep track of the changes.

@Codewrinkles

2 жыл бұрын

When you update a record, you load it, update what needs to be updated and the context will be disposed afterwards.

@oliverharvey7561

2 жыл бұрын

@@Codewrinkles thanks for the reply, but surely the context is not disposed "afterwards" - it is surely disposed when execution exits the "using" block in the OnInitializedAsync block (seen at 14:00) - which is as soon as the entities have been loaded. I'm surprised the entities (which are stored in an arrary) are even usable after the using block completes - let alone find a way to be updatable.

@richardaubin1951

Жыл бұрын

@@oliverharvey7561 I fyou need to update a record, you will need to manage the state of the entity yourself.

New accronym SLAP (Short Lived As Possible)

@Codewrinkles

2 жыл бұрын

Good one :)

くさんありますありがとうございます」、

Damn, is that background music annoying.

you think it is really right way to implement all database and CRUD logic into presentation layer?

@Codewrinkles

Жыл бұрын

Lol, obviously not and that's not the point of the video as I mentioned at least twice during the video. The point of the video is to make people understand that we should use IDbContextClientFactory with Blazor Server and not the regular DbContext. And the best way to showcase this is to actually use it in components, where everybody can see the idea in action that we just create a dbContext WHEN WE NEED IT and dispose it immediately afterwards. And that's also why I have created a dedicated video in which I show how to use IdbContextFactory in handlers or in services.