7

Possible Duplicate:
Why do I need an IoC container as opposed to straightforward DI code?

I read some articles on this topic and I didn't find any brilliant advantages. For example this code:

//some action in a controller
//simplest solution:
var repository = new EmployeeRepository();
var model = repository.ListAllEmployees();

well you may say: in this solution, the controller/action very much depends on the EmployeeRepository. The dependency resolution is:

var repository = DependencyResolver.Current.GetService<IEmployeeRepository>();
var model = repository.ListAllEmployees();

I didn't find it any better than the following one without any dependency resolution/ioc:

var model = Managers.EmployeeManager.ListAllEmployees();

Hope someone can give me some ideas/links/posts on this topic.

Community
  • 1
  • 1
Cheng Chen
  • 42,509
  • 16
  • 113
  • 174

2 Answers2

13

Your example with the DependencyResolver is not much better than your original code, so yeah.. there's not much advantage of doing that.

Thankfully, that's not the way you're supposed to do it. Instead, you use constructor or property injection.

I agree with @adriaanp, easier unit testing is only a side benefit of dependency injection. The greatest benefit is that it encourages dependency free architecture. Your classes stand alone, and do not depend on a specific implementation (other than it's interface and requirements)

Another advantage is that an IoC container can control the lifetime of your dependencies. Suppose you want an object to exist for the lifetime of the request in web page. Also suppose that you want to access this object in many different classes. You could create the object in your page load event, then pass it around to every object you create that needs it. However, this can mean you need to pass it to objects that don't actually use it, simply because they create objects that need it (or they create objects that create objects that need it, or.. and so on).

With dependency injection and an IoC container, the container controls the lifetime of the object, and it deals with injecting it into objects that need it. You don't have to build this into your designs. You just get it for free.

And finally, for the testing issue. When you test something, if it has a hard coded new in there, you can't easily replace it with a mocked object to feed it test data. Suppose you want to test that an object calculates a value correctly. Feeding it test data with known values makes it easier to test.

Erik Funkenbusch
  • 92,674
  • 28
  • 195
  • 291
6

The main advantage of inversion of control is decoupling. By decoupling you improve maintainability. Your controller/action depends on the interface and the implementation is injected into the controller.

Dependency resolution through an IoC container simplifies the dependency injection logic for your controller by configuring the container. Where this really becomes clear is if one class depends on a service, that service depends on other services and those services could also depend on more services, the container will handle that dependency resolution.

A lot of people might tell you to implement inversion of control to be able to test your code, this is not what inversion of control offers, it does make your code more testable but it is not the main reason.

adriaanp
  • 2,064
  • 2
  • 22
  • 40