I need to scan an assembly and, for each type that implements some interface (let's say IFoo) I need to register it with the container for later resolution. Say I have an IFoo class that takes 2 parameters in an assembly
public class MyFooA : IFoo
{
public MyFoo(SomeRandomObject o, ILogger logger)
{
}
}
I have already registered ILogger with the container, and I need to resolve IFoo from it, but at resolution, I need to provide SomeRandomObject o (this can't be in the container). I should only have one implementation for the IFoo so I don't need to specifically name it (at least not yet)
Also note that the implementation of IFoo is found via reflection and the number/type of parameters it has is unknown until it's found.
How do I register and resolve these?
Thanks!
Related
I am trying to use the in built methods of MongoRepository<T,ID> interface to interact with mongo.
interface MovieRepository : MongoRepository<Movie, String> {
}
But when I try to implement the "MovieRepository" using class. Its asking me to implement all the member functions defined in "MongoRepository" as well
class ControllerClass(private val MovieRepository: MovieRepository): MovieRepository {}
This is what i get when i initialize my controller class:
Class 'ControllerClass' is not abstract and does not implement abstract member public abstract fun <S : Movie!> save(entity: S): S
Is there any way so that i do not need to defined all those MongoRepository's functions again in my ControllerClass?
You don't usually implement a repository interface yourself: you let Spring do it for you!
First, you define your interface, as you have done:
interface MovieRepository : MongoRepository<Movie, String> {
// Add any abstract methods you'll need here…
}
Then, you autowire a property of that type. In Kotlin, you can either do it in the primary constructor, e.g.:
#Controller
class ControllerClass #Autowired constructor(
private val movieRepository: MovieRepository
) {
// …code…
}
Or as a plain property. (In this case, because you can't specify an initial value, you have to make the property a var; it must either be nullable — requiring !! everywhere you use it — or, better, make it lateinit.)
#Controller
class ControllerClass {
#Autowired private lateinit var movieRepository: MovieRepository
// …code…
}
Spring will then create some synthetic class implementing that interface, and set your property to it. (You don't need to worry about how it does that — just as you don't need to worry about all the other magic it does, much of which involves creating synthetic subclasses. That's why Spring objects generally need to be made open — and why there's a Spring plugin which takes care of doing that.)
It's more usual to use the repository in a service class, and then call that from your controller class — at least, that pattern tends to scale better, and be easier to follow and to test. But doing so directly should work too. Either way, you can call whichever repository method you need, e.g. movieRepository.findAll().
See the Spring docs; they use Java, but it's mostly trivial to convert to Kotlin.
Java allows the following code to compile. Excuse the naming. I would have chosen better names if I knew why one would write this code, but that is the whole reason for my question. Note that IFace3 extends IFace1 both directly and indirectly (through IFace2). Is there a practical use for this capability?
public interface IFace1 {
public void meth1();
}
interface IFace2 extends IFace1 {
public void meth2();
}
interface IFace3 extends IFace1, IFace2 {
public void meth3();
}
The situation where multiple inheritance causes problems is when a member is defined different ways on different inheritance paths. At least in the days before Java allowed default interface implementations in the middle of a hierarchy, it wasn't possible for part of an interface to be defined in conflicting ways on different inheritance paths, since the actual implementation of every interface member would need to be contained in the class that implements it. Even if an interface includes Interface1.Method1 both directly and by extension through Interface2, the same method in an implementing class will be used to satisfy the members of both interfaces.
I'm devolping a WPF application, using Prism 7.2. I have a module, which implements the IModule interface, where I register the views and viewmodels in the RegisterTypes method, e.g.:
containerRegistry.Register<IPanelOptimizationViewModel, PanelOptimizationViewModel>();
The problem arises when I try to resolve the implementation:
var vm = containerProvider.Resolve<IPanelOptimizationViewModel>();
whereupon I get the following Unity.ResolutionFailedException:
'Resolution failed with error: No public constructor is available for type
XXX.Infrastructure.Interfaces.IView.'
The PanelOptimizationViewModel class derives from a base class:
public class PanelOptimizationViewModel : ViewModelBase, IPanelOptimizationViewModel
{
public PanelOptimizationViewModel(IPanelOptimizationView view, IPanelOptimizationInputViewModel inpVM) : base(view)
}
and the ViewModelBase looks like this:
public class ViewModelBase : BindableBase, IViewModel
{
public IView View { get; set; }
public ViewModelBase(IView view)
{
View = view;
View.ViewModel = this;
}
}
The interfaces IView and IViewModel are defined in a common Infrastructure project. They are not registered anywhere in the container, but if I remove the IPanelOptimizationInputViewModel parameter, no runtime exception is thrown - leading me to think that I don't need to do this, either.
As far as I have been able to understand, the Unity.Container will use the "most parameterized" constructor (see Unity not using the default constructor of the class), but I cannot provide a parameter in the Register method to specify this, as one apparently could before (pre Prism 7's container abstraction), with the RegisterType method.
How to solve this? Is there an overload of the Prism.Ioc.IContainerRegistry.Register method that allows me to set up the registration for constructor injection?
Should I work directly with the Unity container?
Basically, I am trying to inject a child view's viewmodel into the constructor of my "main" viewmodel, but this does not go well as long as the wrong constructor is called on the base class, with the wrong set of parameters... (if that is what is happening).
Needless to say, all child views and viewmodels have been registered in the RegisterTypes method in the module.
Any help on this would be greatly appreciated
Should I work directly with the Unity container?
Yes, you can evade Prism's "abstraction" of the container by calling the GetContainer() extension method (for your container).
containerRegistry.GetContainer() // here you get a plain IUnityContainer
.RegisterType( ... );
This involves autofac and c#. I have an interface derived from a parent interface:
public interface IJ4JLogger<out TCalling>
{
}
public interface IJ4JSmsLogger<out TCalling> : IJ4JLogger<TCalling>
{
}
Certain classes depend on being supplied an instance of the parent interface during construction:
public FileHistoryConfiguration( IJ4JLogger<FileHistoryConfiguration> histLogger, IJ4JLogger<FileHistoryService> svcLogger )
{
}
But if I register the type like this with autofac:
builder.RegisterGeneric( typeof(J4JSmsLogger<>) )
.As(typeof(IJ4JSmsLogger<>))
.SingleInstance();
where J4JSmsLogger<> is a class implementing IJ4JSmsLogger<>, then this call fails with an error that it can't find anything registered to provide an IJ4JLogger<> interface:
_fhConfig = _svcProvider.GetRequiredService<IFileHistoryConfiguration>();
I can work around the problem by changing the As<> clause in the registration of J4JSmsLogger<> to treat it as a IJ4JLogger<> instance, and then cast the result of resolving that interface to IJ4JSmsLogger<> whenever I need the extra capabilities of the child interface.
But I don't understand why I have to do that. Is there an additional step I need to take during registration of the types with autofac so that objects implementing the child interface will satisfy a need for the parent interface?
Cleaner Workaround
Reading more about autofac I learned something new: you can define as many As<>() clauses (including AsSelf()) as you want. So changing my autofac configuration to:
builder.RegisterGeneric( typeof(J4JSmsLogger<>) )
.As(typeof(IJ4JSmsLogger<>))
.As(typeof(IJ4JLogger<>))
.SingleInstance();
provides a cleaner solution than constantly casting resolved instances.
I'm not going to submit it as an answer, though, because I am curious why autofac doesn't do this kind of downcasting automatically, and whether any other DI frameworks do.
Autofac won't cast to base types for you like that. It generally assumes wiring is exact. You could run into some real problems if it didn't, like if someone has a constructor like...
public class BadTimes
{
public BadTimes(object input) { }
}
Which object does it put in there? Everything casts down to object.
However, you could always register it as both types and call it a day:
builder.RegisterGeneric(typeof(J4JSmsLogger<>))
.As(typeof(IJ4JSmsLogger<>))
.As(typeof(IJ4JLogger<>))
.SingleInstance();
I'm trying to inject TenantProvider into DbContext
public class AppDbContext : IdentityDbContext<ApplicationUser, ApplicationRole, long>
{
public int? _tenantId;
public ITenantProvider _tenantProvider;
public AppDbContext(
DbContextOptions<AppDbContext> options,
ITenantProvider tenantProvider
)
: base(options)
{
_tenantProvider = tenantProvider;
}
but I don't understand how to register it correctly - if I put the breakpoint in the constructor - tenantProvider is null.
The bit from Startup.cs
services.AddDbContext<AppDbContext>(options => AppDbContextOptionsBuilder.Get());
the next line is required to inject the DbContext into a controller or a service (if I add ServiceLifetime.Scoped as a second parameter to the method above - AddDbContext - the feature doesn't work):
services.AddScoped(p => new AppDbContext(AppDbContextOptionsBuilder.Get(), p.GetService<ITenantProvider>()));
(Entity Framework is a separate project in my solution)
When using .AddScoped method - we can pass TenantProvider into constructor by resolving it using .GetService method.
Does anyone have an idea of how to resolve TenantProvider in .AddDbContext method?
Additional info:
I was trying to replace ITenantProvider in the constructor of DbContext with IHttpContextAccessor - the latter is registered as singleton. But the acessor parameter is still null.
services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();
I don’t really understand what your AddScoped call is supposed to do. AddDbContext will already register the database context properly with the service collection. So when you resolve the context through dependency injection, additional dependencies will be automatically resolved.
So it should be enough to do this:
services.AddDbContext<AppDbContext>(options => …);
services.AddSingleton<ITenantProvider, TenantProvider>();
And then, you can depend on your AppDbContext using constructor injection, e.g. in your controllers.
Two notes though:
When configuring options, you should modify the passed options object. So you should not just return AppDbContextOptionsBuilder.Get() but instead use the passed options object and edit that.
You should really think about whether your database context having a dependency on your tenant provider is the right thing to do. As per SRP, your database should only do a single thing and that is provide database access.
Depending on how your tenant provider affects your database access, it might make more sense to move this dependency up one level into some service that uses both the database context and the tenant provider to query data in the right way.