Question 85922 in ASP.NET Question posted in
The official documentation can be found here.

How to define DbContext scope in WPF application similar to ASP.NET?

I want to use same technology to access my database both from ASP.NET MVC and WPF and decided to use EF Core.

In ASP.NET I can inject DbContext(UnitOfWork, AppBLL etc) into Controller and its lifecycle is scoped to request/response operation. As I understood the scope is created behind the scenes using ASP.NET middleware pipeline.

In WPF however scope must be defined based on the app use case which is completely logical since some times there is need for long operation (for example using DbSet.Local.ToObservableCollection() and DataGrid) and sometimes operation is more trivial (for example update one entity).

I want to achieve somewhat similar behavior to ASP.NET MVC in WPF, basically I want to inject DbContext into ViewModel constructor and then each method to be its own scope thus have different short-lived DbContext each method call.

I use Microsoft.Extensions.DependencyInjection and CommunityToolkit.MVVM for DI and add DbContext using AddDbContext. This makes it scoped but without defining the scopes it is effectively singleton. I do not want to define scope with using(var scope = …) and GetRequiredService each time I make a db operation since it will pollute my code.

As I said I want it to be sleek like in ASP.NET.

So I tried aspect oriented programming with PostSharp but feels kinda dull to add attributes to each method that uses DbContext also there are concerns about testability.

I tried implementing abstract class which has methods to which lambda with operation is passed and lambda is created inside a using(var scope = …) expression and thus uses scoped DbContext. At the disposal of the scope DbContext is automatically disposed with it.
These approaches however are still distant from ASP.NET mechanism and
I want DbContext lifecycle to be managed smarter.

If I define DbContext as transient then it is only created on injection into ViewModel and not re-created for methods.
By the way, do I understand correctly that in ASP.NET when DbContext is injected into Controller it is disposed right after the construction, since the scope is finished?

EDIT:

Here is a link to example project Github repository

https://github.com/anguzo/ef-core-in-wpf-example

WpfApp project is example of the problem – you can’t update same entity twice since it’s already being tracked.

Other WPF projects demonstrate different solutions to this problem I came up with.

The closest to the ASP.NET behavior is using PostSharp custom attribute. It requires attribute to be applied to ViewModel class and modifies each method(excluding "special methods": getters, setters and consturctors).

I am still lost since official Microsoft documentation and other materials on the Internet do not describe proper solution to this problem.

Tags:

2

Answers


  1. 0

    The dependency injection container is an instance class.

    With mvc there is a request pipeline that provides the parameters of anything instantiated by it from that container.

    The difference between mvc and wpf is that with wpf you don’t have that pipeline so you need to provide the container instance somehow whenever you instantiate a class you want anything injected to.

    It’s covered pretty well here:

    https://learn.microsoft.com/en-us/windows/communitytoolkit/mvvm/ioc

    You do not want everything to be a singleton and you do not want to resolve the entire object graph as you crank up your application.

    As you spotted, that’s impractical anyhow because you want some things to be transient.

    Passing the DI container around is a nuisance. You might have any number of layers down to your dbcontext.

    What is usual is to make the injection container available throughout the app.

    In the code there, they’ve added a property to App to stash that instance in:

    public sealed partial class App : Application
{
    public App()
    {
         Services = ConfigureServices();

         this.InitializeComponent();
     }

    /// <summary>
    /// Gets the current <see cref="App"/> instance in use
    /// </summary>
    public new static App Current => (App)Application.Current;

    /// <summary>
   /// Gets the <see cref="IServiceProvider"/> instance to resolve application services.
   /// </summary>
   public IServiceProvider Services { get; }

    App.Services is your dependency injection container. The magic bag you grab your instances out of.

    Where these services are registered they’re all singletons there, but your dbcontext should be

      services.AddTransient<IMyDbContext, MyDbContext>();

    And your repository would take an IMyDbContext in it’s constructor which would be supplied out the container.

    You need to reference that container exposed by App to resolve an instance:

      var repo = App.Current.Services.GetService<IRepository>();

    Because it’s on App.Current, everywhere in your code will be able to reference it. So long as you have a regular wpf entry point.

    Your repository would get an instance of dbcontext via injection and you’d so whatever you’re doing with that repository. Once it goes out of scope the repository and dbconnection would be ready for garbage collection so long as they’re both Transient.

    Transients will be disposed after they go out of scope. Hence if you pass a transient dbcontext down from a mvc controller then it will stay in scope until the response is sent from the controller. It’s only going to be torn down after the controller’s returned it’s result and goes out of scope.

    The aspect of the code which I would change is to add an abstracted facade around the di container. You want to be able to moq whatever grabs a class instance out that container if you use it within any classs. If you use app.current in unit testing then you need to instantiate an application object.

    Login or Signup to reply.
  2. 0

    What Andy outlines is pretty much what I use, it’s commonly referred to as a Service Locator pattern, and has a bit of a reputation as an anti-pattern, but for WPF it is pretty effective if you have some discipline within your team about where and how it is allowed to be used.

    I’d recently written a quick snippet on using the ServiceLocator pattern and lazy dependency properties with Autofac which can provide some ideas on how the pattern can be applied:

    private readonly IContainerScope _scope;

private ISomeDependency? _someDependency = null;
public ISomeDependecy SomeDependency
{
    get => _someDependency ??= _scope.Resolve<ISomeDependency>()
        ?? throw new ArgumentException("The SomeDependency dependency could not be resolved.");
    set => _someDependency = value;
}

public SomeClass(IContainer container)
{
    if (container == null) throw new ArgumentNullException(nameof(container));

    _scope = container.BeginLifetimeScope();
}

public void Dispose()
{   // TODO: implement proper Dispose pattern.
    _scope.Dispose();
}

    This gives you a pattern gives you a default lifetime scope for the life of a top-level dependency which could be a MVVM ViewModel, and/or navigation provider, etc. so your dependencies can be managed by Transient, Singleton, or PerLifeTimeScope. (Suited to something like the EF DbContext) So for instance when a form is loaded the DbContext instance can be resolved for the lifetime of that form.

    I call the pattern a lazy property pattern as the actual dependency is resolved only if/when it is accessed via the property. The advantage of this is when writing unit tests with classic constructor injection, you need to mock every dependency for every test, where with "lazy" properties you use the Setter for just the dependencies you need. The initialization of the class under test accepts a mocked container that simply throws an exception to fail the test if it’s Resolve<T> method is called. (No need to build a functional mock container for tests to resolve mocked dependencies or other such complexity)

    The caveat of this pattern, and one suggestion to work with the team on to check is that the _scope reference should only be accessed from the dependency properties, not willy-nilly through the code to resolve dependencies ad-hoc. For instance if a new dependency is needed, declare the property accessor to resolve via the scope rather than just writing a _scope.Resolve<NewDependency>() in the code. While you can still test around such code, you’d need to set up your tests to provide a _scope capable of resolving a Mock, which is honestly messy. Following the property pattern makes testing a lot simpler to provide the expected dependency via the Setter and getting an exception/failure if an unexpected dependency happens to get accessed.

    It’s not proper-C#-Lazy, though I do use a proper Lazy dependency pattern for injected dependencies, and web projects where the lifetime scope is conveniently managed:

    private readonly Lazy<ISomeDependency>? _lazySomeDependency = null;
private ISomeDependency? _someDependency = null;
public ISomeDependency SomeDependency
{
    get => _someDependency ??= _lazySomeDependency?.Value
        ?? throw new ArgumentException("SomeDependency dependency was not provided.");
    set => _someDependency = value;
}

public SomeClass(Lazy<ISomeDependency>? someDependency = null)
{
     _lazySomeDependency = someDependency;
}

    Autofac does support lazy initialization so this pattern means that for normal execution, Autofac provides the properties as Lazy references which will resolve if/when they are accessed. For unit tests, you just initialize with an empty constructor and use the Setters to set the dependencies you expect to actually be used. The above example with 1 dependency doesn’t really demonstrate the value of that, but picture a test suite for a class that has 8 or 12 dependencies where a method under test will likely only touch a couple of them.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search