Property dependency injection used in constructor using Unity

Well, I have a dependent property defined in the base class, and I'm trying to use it inside the constructor of its derived class, but this does not work, the property is displayed as null. Unity resolves the dependent property AFTER resolving the instance with the container. Resolve ();

One alternative is to add the IUnityContainer parameter to my constructor for the MyViewModel class and set the ILogger property for yourself:

public MyViewModel(IUnityContainer container) { Logger = container.Resolve<ILogger>(); } 

EDIT: Another @Wiktor_Zychla suggestion is to pass the parameter introduced by the constructor as:

 public MyViewModel(ILogger _logger) { Logger = _logger; } 

Everything seems to work just fine, but I would have to do this for all of my ViewModels derivatives.

But then I do not use the annotated ILogger dependency in the base class. See my class examples below. The question is, what are my alternatives or what am I doing wrong?

Thanks!

I have a ViewModel base class, for example:

 public abstract class ViewModelBase { [Dependency] public ILogger Logger { get; set; } .... } 

Then I have a class getting:

 public class MyViewModel : ViewModelBase { public MyViewModel() { //I want to use my dependent property in constructor, but doesn't Logger.Error("PRINT AN ERROR"); } } 

And at the entry point of my application, I register my ILogger as singleton and my MyViewModel class:

 container.RegisterType<ILogger, MyAppLogger>(new ContainerControlledLifetimeManager()); container.RegisterType<MyViewModel>(); 
+4
source share
2 answers

Unity allows the dependent AFTER property to resolve the instance with container.Resolve ();

This is quite obvious if you think about it. Just try to do it manually. You will not succeed. To be able to enter a property, there must be an instance and having an instance means that the constructor has been called.

Your problem is caused by the fact that you work too much in your constructor. From the perspective of dependency injection, the constructor should do nothing more than accept its dependencies (check that they are not zero) and store them in private fields. Doing something bigger than this is an anti-pattern. You should not have any logic in your constructor.

The presence of logic in the constructors makes the creation of an object graph unreliable, and the construction of object graphs should be fast and reliable.

When you follow this principle, there will be no problems, because after starting any business logic your class will be completely created. Since the constructor must do nothing more than set private fields, nothing can go wrong and there can be no reason to call Logger.Error("PRINT AN ERROR"); how you do it.

+7
source

1) You can use a different instance of your registrar in each view model by simply dropping the ContainerControlledLifetimeManager .

2) You can register a different Type recorder for each viewing model, indicating it during registration.

 container.RegisterType<ILogger, MyAppLogger>(); container.RegisterType<ILogger, MyOtherLogger>("uniqueNameOfAnILoggerRegistration); container.RegisterType<MyViewModel>(new InjectionConstructor( new ResolvedParameter(typeof(ILogger), "uniqueNameOfAnILoggerRegistration"))); 

Using the constructor installation, a new instance of MyOtherLogger will be added to your view model.

Since property nesting should be reserved for "nice to have" values, and your classes obviously rely on the existence of a registrar, I highly recommend using ctor injection.

+2
source

All Articles