Property and method Injection in ASP.NET Core Web API

How does one implement property and method dependency injection? How do I add the services? And finally, how good of an impact can that have compared to using constructor injection?

Is it possible to use property/method injection instead of constructor injection?

.Net beginner here and all the help would be appreciated <3

In my wrapper class where I am using constructor DI:

private ICustomerRepository _customerRepository; //For customer
private ICountryRepository _countryRepository; //For country
private IRegionRepository _regionRepository; //for region
private ICityRepository _cityRepository; //for city

// Constructor 
public RepositoryWrapper(OmniConnectDB context, ICustomerRepository customerRepository, IMapper mapper, ICountryRepository countryRepository, IRegionRepository regionRepository, ICityRepository cityRepository)
{
    _context = context;
    _mapper = mapper;

    _customerRepository = customerRepository;
    _countryRepository = countryRepository;
    _regionRepository = regionRepository;
    _cityRepository = cityRepository;   
}

In services:

// configure DI for Location Repositories
services.AddScoped<ICountryRepository, CountryRepository>();
services.AddScoped<IRegionRepository, RegionRepository>();
services.AddScoped<ICityRepository, CityRepository>();

// Configure DI for Customer Service
services.AddScoped<ICustomerService, CustomerService>();

As explained in https://stackoverflow.com/questions/38459625/property-injection-in-asp-net-core, you don't get property injection out of the box, but you can add it through extensions such as Quickwire or by using a different DI/IoC container altogether (such as Autofac).

But:

> how good of an impact can that have compared to using constructor injection?

None whatsoever, but you get all of the drawbacks: a class's dependencies are not obvious (you can't get around a constructor), you can leave dependencies null, causing later errors and hindering compile-time safety.

> I am following the repository design pattern in which the norm is to create "repository" classes. And the reason for the wrapper is so that I don't have to make objects of all my different user classes in every API [...] https://code-maze.com/net-core-web-development-part4/

This is an antipattern of antipatterns. It is kind of like a service locator, wrapping all the functionality that Entity Framework offers in more limited, equal services with less functionality and less documentation.

So instead of injecting an YourAppDbContext and accessing its members DbSet<Foo> Foos { get; set; }, you inject a RepositoryWrapper (which is the same thing as the DbContext, but can do less) and obtain ... its Foos property.

Skip this tutorial.

There's no property and method injection in .NET Core itself. The DI middleware supports only constructor injection. The ASP.NET Core middleware does offer a form of action injection, but only for action parameters.

app.MapPost("/todoitems", async (Todo todo, TodoDb db) =>
{
    db.Todos.Add(todo);
    await db.SaveChangesAsync();

    return Results.Created($"/todoitems/{todo.Id}", todo);
});

In this example the TodoDb DbContext is injected.
This was added to enable Minimal API support but benefits controller actions as well.

public IActionResult About([FromServices] IDateTime dateTime)
{
    return Content( $"Current server time: {dateTime.Now}");
}

This isn't a DI middleware feature though and can't be used for other classes. The ASP.NET Core middleware inspects the API methods, identifies any injected services and asks the DI container for instances. I think that's done using source generators at compile time.

Logically, the middleware will:

• Ask the DI middleware to create a new controller instance
• Inspect the action for parameters to inject and
• Finally call the action method with the bound and injected parameters.

The FromServices attribute can be inferred in some cases. This is explained in the section Binding Source Parameter Inference. The ASP.NET Core middleware will check whether any of the parameter types are registered with DI and use DI automatically.

If you want to use method injection for other code you'll have to either use a different DI container or write code that does what ASP.NET Core does itself.