CODEWITHSUNDEEP
mvvmdependenciescode-injection
user823486
user823486

Reputation: 149

MVVM Dependency Injection

I'm in the process of teaching myself the MVVM pattern by dividing the pattern into its core facets and learning those facets one by one.

My question is related to dependency injection. What is it, and why/when should I use it? I've looked at Jason Dolinger's excellent MVVM intro video and I see he uses Unity. This might be strange to ask but how would I implement dependency injection WITHOUT using Unity? I basically want to understand the concept of dependency injection and how to use it without having to implement other frameworks/tools (for now).

Thanks.

Upvotes: 2

Views: 1455

Answers (2)

StuartLC
StuartLC

Reputation: 107237

Just to extend @Andy's answer

Dependency Injection is one of the forms of the Dependency Inversion Principle

To achieve the decoupling of dependencies (as typically found in layered architecture), DI is commonly used for instantiation scenarios such as basic new() and patterns like Factory method. In addition to being able to inject a new dependency instance every time (e.g. like factory), containers can also be set up to inject named instances, singleton instances, etc - i.e. IoC containers usually also take on the responsibility of managing the lifespans of objects as well.

One potential 'mindset shift' is that dependencies now potentially become publicly visible on concrete classes, since DI typically injects via constructors or public Get / Set properties. This may seem strange if you are used to using OO encapsulation, where dependencies of a class are seen as implementation and should be hidden from the 'outside' i.e. class method signatures. However, by implementing Interface / Concrete class separation (as you should, not only for decoupling but also for testing / mocking purposes), the injection constructors / property injection methods will not be on the interface, so encapsulation is again in place.

Re : "Doing DI by hand" without Unity etc

What you would need to do is to code your own IoC container, which then is responsible for 'building up' instances of classes - during each 'build up', you would scan the class for dependencies (which are configured in the container, e.g. by config, by attributes, or simply just by convention, e.g. all public settable properties, or any class parameters on a constructor will be assumed to be dependencies). You would then create (if necessary) and inject this 'dependency' instance onto the object (e.g. by using reflection). And then recursively, all dependencies of these dependencies need to be built up etc. You would then also need to provide lifespan management for each of the objects, e.g. Singletons etc.

Upvotes: 0

Andy Gaskell
Andy Gaskell

Reputation: 31761

I think it's good that you want to understand DI without using a framework, the concept is not terribly difficult to wrap your head around.

Let's say you want to use some form of transportation. 

interface ITransportation 
{
  Transport();
}

An initial implementation of a method that uses a form of transportation might look like this:

public void Move()
{
  ITransportation car = new Car();
  car.Transport();
}

The problem with that method is that it is now dependent on a Car class. We should pass our transportation object in for added flexibility. This is inversion of control and is closely related to DI.

public void Move(ITransportation tr)
{
  tr.Transport();
}

As you can see, we don't need to know anything about a specific DI framework. You might also want to check out the ninject DI by hand tutorial.

Upvotes: 2

Related Questions