1

Is there a way to instantiate a class without a constructor if I don't have a handle to the container?

If I call container.RegisterType<IMyClass , MyClass>() I know I can use unity to instantiate an object in a constructor.

Someclass(IMyClass myClass)

var s = new Someclass();

I also know I can use container.Resolve<IMyClass>() outside a constructor if I have a handle to the container, or use the DependencyFactory, which is also the same thing.

If I am writing code for a large project that doesn't save a handle to the container, and it is not appropriate to use a constructor, is there a way to instatiate class using unity?

Brad
  • 1,360
  • 4
  • 18
  • 27
  • 2
    In short if you do IOC correctly the first class you resolve will then mean everything there on will be resolved as you go... So, you resolve `MyClass` which in turn would have something like `IAnotherClass` which would be auto resolved and so on. After one level deep you should not be aware of Unity etc and all the magic happens as close to the entry-point of your app as possible. – Belogix Jul 06 '15 at 15:22

1 Answers1

2

you should not be referencing the container in your classes. You container should be orchestrating the construction of the object graph and your class should not be calling it, it should be calling your classes.

Ideally your container should not be used outside of the Composition Root. See this answer

The point I (and Belogix) was trying to make (not very well it seems) is that you should never need to create dependent objects directly if you are using DI correctly. Passing the container around is a code smell and you should avoid this if at all possible (which it almost always is). If you require an instance of a class in a place where you 'don't have a handle to the container' you should be asking for an instance of that class through your object's constructor. Doing this allows the IoC container to know that your object has a dependency and it can then supply an instance of that dependency when the container creates an instance of the class. If you follow this principal with every dependency all the way up your chain then your composition root becomes the only place that you need to create your objects, and you can do it manually (poor man's DI), or you can configure a container to do it for you.

I suggest you read this post it really helped me understand the concept of a composition root and why not leaking your container throughout the application is a Good Idea.

If you want to create an object without calling the constructor and without a handle to the container then you can use GetUnitializedObject as outlied in this answer but you have to ask yourself, if you are swimming that hard upstream to create your objects, surely there must be a better way?

I was only trying to point out what I consider the currently accepted best practices around using a container.

Community
  • 1
  • 1
Sam Holder
  • 32,535
  • 13
  • 101
  • 181
  • Would you consider this bad code? https://msdn.microsoft.com/en-us/library/vstudio/hh323690%28v=vs.100%29.aspx And how is this relevant to my question on whether I can construct objects WITHOUT a handle to the container? – Brad Jul 06 '15 at 18:29
  • I don't know if that is how I would do it, but that code seems ok. It's using the container only in the composition root (the service host factory in WCF) as suggested in the answer I linked to. I have edited my answer with some more information about the (bad) idea of creating objects without using the constructor or container, but also tried to explain what is a better approach. – Sam Holder Jul 06 '15 at 20:57