Using Entity Framework Core DbContext Pooling with Simple Injector - entity-framework-core

Looking at the examples of how to use db context pool I see it was designed to be used with ServiceCollection:
var serviceProvider = new ServiceCollection()
.AddDbContextPool<AdventureWorksContext>(options => { //options })
.BuildServiceProvider();
But what about Simple Injector? is it possible to register DB pooling in the Simple Injector container?
p.s. My app is not ASP.NET MVC, it's just a kinda DAL

EF Core DbContext pooling in ASP.NET Core
When integrating Simple Injector in ASP.NET Core, you keep framework and third-party components inside the .NET Core configuration system. This means that enabling Entity Framework Core context pooling is done exactly as Microsoft documents it:
services.AddDbContextPool<BloggingContext>(
options => options.UseSqlServer(connectionString));
As Simple Injector does not replace the built-in configuration system, you will have to instruct Simple Injector to automatically load missing registrations (such as your DbContext) from the .NET Core configuration system. This can be done by using the AddSimpleInjector and UseSimpleInjector extension methods, as shown here.
private SimpleInjector.Container container;
public void ConfigureServices(IServiceCollection services)
{
...
services.AddDbContextPool<BloggingContext>(
options => options.UseSqlServer(connectionString));
services.AddSimpleInjector(container, options =>
{
options.AddAspNetCore();
});
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
app.UseSimpleInjector(container);
container.Verify();
...
}
Using this setup, the BloggingContext can be injected into any component that is resolved from Simple Injector, while the BloggingContext is pooled by Entity Framework. For intance:
// Application compoment registered in and resolved from Simple Injector
public class CommentIsNoSpamValidator : IValidator<PostComment>
{
private readonly BloggingContext context;
// Is injected with BloggingContext from IServiceCollection
public CommentIsNoSpamValidator(BloggingContext context)
{
this.context = context;
}
public IEnumerable<ValidationResult> Validate(PostComment command)
{
// Complex business logic here.
}
}
EF Core DbContext pooling in a .NET (Core) Console application
When it comes to using Entity Framework Core context pooling in a .NET Core console application, the solution will be very similar, although you will have to set up a little bit more:
public void Main()
{
var container = new Container();
var services = new ServiceCollection();
services.AddDbContextPool<BloggingContext>(
options => options.UseSqlServer(connectionString));
services.AddSimpleInjector(container);
services
.BuildServiceProvider(validateScopes: true)
.UseSimpleInjector(container);
container.Verify();
// Run application code
using (AsyncScopedLifestyle.BeginScope(container))
{
var service = container.GetInstance<MainService>();
service.DoAwesomeStuff();
}
}
So in the end, the DbContext's lifetime is managed by the MS.DI scope, but that scope is managed by Simple Injector's scope.
EF Core DbContext pooling in a library
In case you are building a library, i.e. a non-startup project, please stop what you're doing. Only the application's startup assembly should have a Composition Root, and only the Composition Root should use a DI Container (such as Simple Injector or MS.DI's ServiceCollection). All other libraries in your application should stay oblivious of the (possible) existence of a Container.

You could use
container.Register(() =>
serviceProvider.GetRequiredService<AdventureWorksContext>());
to have the ServiceProvider resolve the dependency as it's requested.

Adding to #Steven's excellent answer, here's his console application answer, but with the context (implicitly) using UseInternalServiceProvider.
var services = new ServiceCollection();
services.AddEntityFrameworkSqlServer();
services.AddSingleton<Microsoft.Extensions.Logging.ILoggerFactory>(new Microsoft.Extensions.Logging.LoggerFactory());
services.AddSingleton<IInterface>(new MyImplemenation());
services.AddDbContextPool<EFViewAndManyToManyDb>(optionsBuilder => {
optionsBuilder.UseSqlServer("");
});
services.AddSimpleInjector(container);
services
.BuildServiceProvider(validateScopes: true)
.UseSimpleInjector(container);
Here's why you'd want to use UseInternalServiceProvider. TLDR: if your DbContext has a dependencies, e.g. IInterface. You'll also need to add the SimpleInjector.Integration.ServiceCollection Nuget package.

Related

Blazor Server App and IDbContextFactory not disposing

I have a blazor server application that needs to indirectly connect to a EF core DB context.
None of the blazor components will directly inject an instance of the dbcontext. I am using mediator which will handle all business operations.
The documentation that I have seen so far recommends using IDbContextFactory. I gave it a try but I am not seeing the DbContext created by the factory being disposed. The services that inject IDbContext are not disposed on page changes nor at any other time.
public class QueryHandler : IQueryHandler<Query, Entity>, IDisposable
{
private readonly DbContext dbContext;
public QueryHandler(IDbContextFactory factory)
{
dbContext = factory.CreateDbContext();
}
public Task Handle(Query query)
{
/// do whatever needs to be done.
}
public void Dispose()
{
dbContext.Dispose(); // <-- Dispose never gets called.
}
}
Am I missing something?
The purpose of using a DbContextFactory is to have a DbContext per method.
Exactly because Blazor doesn't offer useful Scopes to handle this.
public class QueryHandler : IQueryHandler<Query, Entity> //, IDisposable
{
...
public QueryHandler(IDbContextFactory factory)
{
_factory = factory;
}
public Task Handle(Query query)
{
using var dbContext = _factory.CreateDbContext();
/// do whatever needs to be done.
}
//public void Dispose() { }
}
This way the DI container and Factory only manage the configuration of the DbContext. Lifecycle management of the DbContext is manual. The Factory is a simple Transient object, is owns no resources.
Manual management usually is with a using statement or using declaration but Blazor also offers an OwningComponentBase. I don't see it being used much.
In Server the DI container exists for the lifetime of the Hub Session and in WASM the lifetime of the Application. Any service objects created within the container, whether Scoped or Transient, implementing IDisposable, are not Disposed until the DI container itself is destroyed. You don't make clear the scope of QueryHandler, but if it's transient that's bad news. You will keep creating new DBContexts without the old ones being disposed.
The purpose of the DbContextFactory is to create unit of work DbContext instances that are used and then quickly disposed correctly. You need to take this approach because DB access will almost certainly be asynchronous. Use a single context and you will quickly hit the situation where you are awaiting one query to complete while trying to use the same context in another operation.
Henk's answer shows you how to use and consume factory created contexts.

What is the path from a model to the database?

I have a project created from the ASP.NET Core Web Application template in VS. When run, the project creates a database to support the Identity package.
The Identity package is a Razor Class Library. I have scaffolded it and the models can be seen. The models are sub-classed from Microsoft.AspNetCore.Mvc.RazorPages.PageModel.
I am tracing the code to try and get a better understanding of how it all works. I am trying to find the path from the models to the physical database.
In the file appsettings.json, I see the connection string DefaultConnection pointing to the physical database.
In startup.cs, I see a reference to the connection string DefaultConnection:
services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(
Configuration.GetConnectionString("DefaultConnection")));
After this, I lost the trail. I can't find the link from a model in code to a table in the database. What is the code needed to perform a query like select * from AspNetUsers?
As #Daniel Schmid suggested , you should firstly learn the Dependency injection in ASP.NET Core.
ASP.NET Core has an excellent Dependency Injection feature through which this framework provides you with an object of any class that you want. So you don’t have to manually create the class object in your code.
EF Core supports using DbContext with a dependency injection container. Your DbContext type can be added to the service container by using the AddDbContext<TContext> method.
Then you can use the instance like :
public class MyController
{
private readonly ApplicationDbContext _context;
public MyController(ApplicationDbContext context)
{
_context = context;
}
...
}
or using ServiceProvider directly, less common :
using (var context = serviceProvider.GetService<ApplicationDbContext>())
{
// do stuff
}
var options = serviceProvider.GetService<DbContextOptions<ApplicationDbContext>>();
And get users by directly querying the database :
var users = _context.Users.ToList();
Please also read this article .

Entity Framework ensure OnModelCreating is called

I'm using a dependency injection container for my application, including my EF database contexts. I recently found out that OnModelCreating is not being called because I'm never doing the typical
using(var contexnt = new MyContext)... rigmarole. The constructor for my context looks like:
public UserAccessContext(string connectionString):base(connectionString)
{
this.connectionString = connectionString;
Database.SetInitializer<UserAccessContext>(null);
}
My issue is that in my OnModelCreating I'm mapping a table which isn't reasonably named (outside of my control) to a domain object. EF is trying to use convention to figure out the table name and guessing wrong. How can I keep using DI for injecting the dependency of my context, but also ensure that the configuration code is will be called?
This application is a .NET core application, using the built in DI container for .NET core web api:
services.AddScoped<IUserAccessContext>(_ => new UserAccessContext(userAccessConnectinString));
OnModelCreating configuration
var remediationAuditLogConfig = dbModelBuilder.Entity<RemediationAuditLog>()
.ToTable("dbo.PoorlyNamedTable");
remediationAuditLogConfig.HasKey(x => x.Id);

How to inject dbcontext with StructureMap and WebApi2

I would like to inject my dbcontext into my services in web api 2 project. But I’m a little unsure of how to do that. I've read through the docs but lifecycles, scopes, requests, nested containers...they all leave me a little unsure. I have pieced together the following code from my best understanding. After installing the Nuget package StructureMap.WebApi2, I proceeded to update SM from v3 to v4, as well as the SM.MVC5 from v3 to v4.
The following code appears to have the desired effect of using one dbcontext per http request (I think that's what i want...i'm so confused about scopes) so that the same dbcontext is shared for all services during a users transaction, and then disposed when the transaction (http request) is closed. But appearances are not always right.
IoC.cs
public static IContainer Initialize()
{
var container = new Container(_ =>
{
_.AddRegistry<DefaultRegistry>();
_.ForConcreteType<MyDbContext>().Configure.ContainerScoped();
});
DomainEvents.Initialize(container);
return container;
}}
DefaultRegistry.cs:
public DefaultRegistry()
{
var mapperConfig = new MapperConfiguration(cfg =>
{
cfg.AddProfile(new Common.Map.MapProfile());
cfg.CreateMissingTypeMaps = true;
});
var mapper = mapperConfig.CreateMapper();
For<IMapper>().Use(() => mapperConfig.CreateMapper());
For<MyDbContext>().Use(()=> new MyDbContext());
Scan(
scan =>
{
scan.AssemblyContainingType<ServiceBase>();
scan.TheCallingAssembly();
scan.WithDefaultConventions();
scan.ConnectImplementationsToTypesClosing(typeof(IHandle<>));
});
}
The Nuget package StructureMap.WebApi2 created some other files for wiring up resolution and nested containers, but i'm leaving them out of this question for the sake of brevity.
Have a look at the Mehdime DbContext Scope Factory / Locator: https://github.com/mehdime/DbContextScope and he has a bit of a run-down of it on his blog. (link in the project description.) There are forks off there updated to the latest EF versions.
I've found it to be an excellent unit of work wrapper for EF contexts without having to worry about injecting or passing around those contexts directly.
The trouble with IoC containers and constructor injection is that if you register your DBContext it means that it's hard to work with things like a unit of work within the scope of a request without it essentially being the entire scope of the request. The DbContext Scope solves this by having you register a Scope Factory and a Scope Locator in your Container. Code controlling the Scope (unit of work) will use the Scope Factory to initialize a context scope for your DbContexts. Code operating with DbSets etc. in a DbContext use the ContextScopeLocator to get their UoW /w it's DbContext & sets.

Where do I put my Ioc (ninject) code in my service layer project?

I have 3 project files
webui - controllers and views
framework - service layer and repos
tests- unit tests
So how I see it is that my controllers will only talk to my service layer(that contains my business logic). The service layer will talk to the repos and get database data.
My repo will just talk do the database and return data.
Now if I want to unit test this I need to have fake service layers and fake repositories.
this way I can test the controllers in isolation and the service layers in isolation.
So where do I put my ninject code in my framework class library so that I can use it with my service layer?
Edit
Steven are you saying I should be doing something like this
//setup ninject in global aspx with mvc extension
// now bind the stuff
private class SportsStoreServices : NinjectModule
{
public override void Load()
{
Bind<IAdminService>().To<AdminService>();
Bind<IAdminRepo>().To<AdminRepo>();
}
}
// controller
public class AccountController : Controller
{
//
// GET: /Account/
private IAdminService adminService;
public AccountController(IAdminService adminService)
{
this.adminService = adminService;
}
public ActionResult Login()
{
var getAllAdmins = adminService.GetAllAdmins();
return View();
}
}
// Service Layer
public class AdminService : IAdminService
{
private IAdminRepo adminRepo;
public AdminService(IAdminRepo adminRepo)
{
this.adminRepo = adminRepo;
}
public List<Admins> GetAllAdmins()
{
return adminRepo.GetAllAdmins();
}
}
//Repo
public class AdminRepo : IAdminRepo
{
public List<Admins> GetAllAdmins()
{
// some query to get all admins
}
}
When you follow the Dependency Injection pattern correctly (and completely) the only place you need to reference your IoC container is in your application root (in your case your web project). For MVC you would typically have a ControllerFactory that knows how to create new controllers using your particular IoC framework. Your controllers will be designed around constructor injection so your IoC framework is able to automatically inject all the dependencies. You will typically use constructor injection throughout the whole project. This allows you to let the rest of your code stay ignorant of the choosen IoC implementation.
For unit tests you would normally use constructor injection to manually inject the dependencies. This saves you from having to configure your IoC framework for your unit tests. Using an IoC library in your test project is painful, because you often want different dependencies to be returned per test case and testing frameworks often run your tests in parallel. So best is to not use any IoC framework in your tests, but call the constructor of a type under test yourself.
The trick for unit tests with DI is to keep your unit tests maintainable. You can do this for instance, by extracting the creation of a type under test into a factory method. This allows you to call such a constructor just in one place in your code. When the constructor changes, you would will have to change your test code in one place. I learned a lot about writing maintainable unit tests by the book The Art of Unit Testing. I can recommend it.
At project the DI should be in the place where the object composition can Happen.. For instance in WCF service Project we can do it using IInstanceProvider,IN asp.net Global.asax .
Ground rule:Make sure the DI is the application start up point