2

I'm a newbie to Dependency Injection. I have never used and never even undestood what it is exatcly all about, but after my last attack on this topic I found out that is a way of uncoupling an object and its dependencies, once they are not responsible for instantiating the concrete versions of its dependencies anymore, as now the container will do it for us and deliver the ready object in our hands.

Now the point is; "when should I use it?", ALWAYS??? Actually, as I'm a newbie and have never even seen a project that uses this pattern I can't undestand how I should apply it to my domain objects!!! It seems to me that I will nevermore instantiate my objects and the container will always do it for me, but then comes some doubts...

1) What about oobjects that part of its dependencies comes from the UI, for example;

public class User(String name, IValidator validator)

Say that I get the user name from the UI, so how will the conatiner know it and still delliver this object for me?

2) Theres other situation I'm facing; if a dependency is now an object that is already instantiated, say... a SINGLETON object, for example . I saw theres settings regarding out the scope of life of the dependency beign injected (im talking about Spring.NET, eg; http request scope)... BUT, request and other web related things are on my presentation layer, so how could I link both my presentation layer and my domain layer without breaking any design rule (as my domain should be totally unaware of where its is being consumed, not to have layer dependency, etc)

Im eager to hear from you all. Thanks very much.

Renato Gama
  • 16,431
  • 12
  • 58
  • 92
  • 1
    Lots of DI Questions today =) See if this answer helps. :http://stackoverflow.com/questions/5433211/difference-between-ninject-and-rhinomock-or-moq/5433231#5433231 – gideon Mar 25 '11 at 17:07
  • Its usefull @giddy, thanks, but not exactly the point! =) – Renato Gama Mar 25 '11 at 17:11
  • @Renato just thought it would help explain _why_ one uses DI. =) – gideon Mar 25 '11 at 17:12
  • @giddy indeed it helps my friend! I have read and upvoted your answer it was totally clear to me. Whats happen is that I already get what you explained there, so I guess my doubt is a bit further that question. Thank you for the concern buddy! appreciate! – Renato Gama Mar 25 '11 at 17:21
  • related: http://stackoverflow.com/questions/1943576/is-there-a-pattern-for-initializing-objects-created-via-a-di-container/1945023#1945023 – Mark Seemann Mar 25 '11 at 20:09
  • related: http://stackoverflow.com/questions/4835046/why-not-use-an-ioc-container-to-resolve-dependencies-for-entities-business-object – Mark Seemann Mar 25 '11 at 20:11
  • related: http://stackoverflow.com/questions/1475575/where-should-i-do-dependency-injection-with-ninject-2 – Mark Seemann Mar 25 '11 at 20:12
  • related: http://stackoverflow.com/questions/150980/dependency-injection-book-recommendations – Mark Seemann Mar 25 '11 at 20:13
  • @Mark thanks, I'm gonna check it all out!!! – Renato Gama Mar 25 '11 at 20:16
  • @Renato: No problem. Most of your questions seem to be of a conceptual nature. Some of the links I provided may at first glance seem irrelevant to you because they ask about other containers etc. but you should be able to extract some general guidelines out of the answers. – Mark Seemann Mar 25 '11 at 20:27

3 Answers3

1

1) this contructor is probably not the right one to use, may be you are injecting the validator in the wrong place/way.

2)Neighter View nor Model and nor Controller should be aware of there is an IoC, it should lie in the background architecture ( where MVC components are actually instantiated )

You should use IoC when you feel the architecture can became complex and has to be mantained by many people. If you are writing an enterprise application, or a UI you think to extend with plugins, you probably need it, if you are writing a command line utility, probably not.

Felice Pollano
  • 32,832
  • 9
  • 75
  • 115
1

You should use dependency injection whenever you want any of the following benefits:

  • The ability to replace modules easily
  • The ability to reuse modules between parts of the application, or different applications
  • When you want to do parallel development, so that components of a system can be developed in isolation and in parallel because they depend on abstractions
  • When you want easier maintenance of a system because of loose coupling
  • When you want testability (a specialisation of replacing modules). This is one of the biggest reasons for using DI

To answer your other questions:

1) You can configure many IoC containers so that certain constructor parameters can be specified, whilst others are resolved by the container. However, you may need to think about refactoring that piece of code, as a UserFactory may be more appropriate which takes the validator dependency, and has a NewUser method which takes a user name and returns a new user (either instantiating it directly or resolving from the container).

2) Each application you build will have a composition root, where your container is configured, and the root object is resolved. Each app will therefore have its own IoC configuration, so there is an expected link between the application type and the configuration settings. Any common abstraction registrations can be placed in configuration code which can be shared amongst all applications.

devdigital
  • 34,151
  • 9
  • 98
  • 120
1

In general, once you go IoC, you tend to want to register EVERYTHING with IoC and have the container spit out fully-hydrated objects. However, you bring up some valid points.

Perhaps a definition of "dependency" is in order; at its broadest, a dependency is simply a set of functionality (interface) that a given class requires a concrete implementation of in order for the class to work correctly. Thus, most non-trivial programs are full of dependencies. To promote ease of maintenance, loose coupling of all dependencies is generally preferred. However, even when loosely coupled, you don't need to automate instantiation of dependencies if those objects require specialized information that you don't want to pollute your IoC registry with. The goal is to loosely couple usage, not necessarily creation.

Concerning point 1, some IoC frameworks don't do well with being given external parameters. However, you can usually register a delegate as a factory method. That delegate may belong to an object like a Controller that is given external information by the UI. Logins are a perfect example: Create an object, say a LoginController, and register it with IoC as your ILoginController. You'll reference that controller on your Login page, it will be injected when the Login page is instantiated, and the login page will pass it the credentials entered. The Controller will then perform authentication, and will have a method GetAuthenticatedUser() that produces a User object. You can register this method with IoC as a Factory for Users, and whenever a User is needed, the factory delegate will either be evaluated, or passed wholesale to the dependent method which will call it when it really needs the User.

On point 2, setting up a single instance of an object is a strength of the IoC pattern. Instead of creating a true singleton, with a private instance constructor, static instance and static constructor to produce an instance, you simply register the class with IoC and tell it to only instantiate it once and use that one instance for all requests. The strength is the flexibility; if you later want there to be more than one instance, you just change the registration. You won't break any design pattern rules either way; the view will always have a Controller injected, whether that Controller is the same for all pages or a new instance per request.

KeithS
  • 70,210
  • 21
  • 112
  • 164