So what do you think of dependency injection?

[Erik Westermann]

Dependency injection was like a solution looking for a problem. While loose coupling is nice, I wasn't convinced that such a high degree of loose coupling is necessary or provides any tangible benefits. I changed my mind when I saw something successfully use it: nServiceBus. nServiceBus' use of dependency injection results in an elegant and functional design that is surprisingly easy to use. I'm still not convinced that DI is ready for broad use since I still believe that it's a specialized approach to handle a specialized problem.

Erik Westermann - ArtOfBabel.com - Systems Integration Magazine
Contact Erik for consulting, development, or content creation at +1 416-809-1453 or via wWorkflow.net

[Marc Clifton]

Todd Smith wrote:

what happens when your DAL needs your HttpContext? Are you going to modify every layer to pass along that value?

Well no, but why not create a simple service container where you can add the HttpContext object, and give that container (in the constructor perhaps?) to classes that need it? Marc

Will work for food. Interacx

[Todd Smith]

Marc Clifton wrote:

Well no, but why not create a simple service container where you can add the HttpContext object, and give that container (in the constructor perhaps?) to classes that need it?

Now your DAL has to know about your Service Manager which has to know about ALL of your other interfaces. You've created a coupling between everything in your system. That's like dipping your Jenga puzzle in a giant vat of glue. Or is your Service Manager type agnostic and you're doing a cast during every service request?

Todd Smith

[Kevin McFarlane]

Not used it in anger but been reading around a bit. There are lighter alternatives to what you've tried though, e.g., Unity and Ninject. But I haven't done much more than "Hello World" with either so maybe they suck too?

Kevin

[Brady Kelly]

Todd Smith wrote:

what happens when your DAL needs your HttpContext?

[Devil's Advocate Mode] Why would it? :~ [/Devil's Advocate Mode]

You really gotta try harder to keep up with everyone that's not on the short bus with you. - John Simmons / outlaw programmer.

[Shog9 0]

Heh, yeah, does seem like a bit of an odd dependency...  I assumed he just picked a class at random to use for an example.

[Shog9 0]

Kevin McFarlane wrote:

Not used it in anger

Ok, that's twice in the last two days i've seen this phrase used in relation to development tools... Are you seriously out there murdering people with text editors on a regular basis? :~

[Brady Kelly]

Kevin McFarlane wrote:

But I haven't done much more than "Hello World"

At least we know their natural language, idiom, and GUI services are OK.

You really gotta try harder to keep up with everyone that's not on the short bus with you. - John Simmons / outlaw programmer.

[emiaj]

You may want to give a try to StructureMap[^] As others had pointed out, one of the coolest things about IoC is the object's lifetime management. Good luck.

Jaime Febres The worst blog in the world

[Kevin McFarlane]

Whether these things have merit or not I find that, as a contractor, it's worth playing around with them a bit if only for interview conversation topics. :-) We quite often get this kind of stuff thrown at us.

Kevin

[Todd Smith]

Shog9 wrote:

Heh, yeah, does seem like a bit of an odd dependency...  I assumed he just picked a class at random to use for an example.

this

Todd Smith

[martin_hughes]

I had a look at these things a while back. I wasn't wholly convinced. I suspect, like everything in IT, these Frameworks solve a certain class of problem and are quite good at it. I can imagine a situation where you have a well defined problem where different parties demand a different approach to solving that problem could be solved using dependency injection. What I am sure about is that zealots got hold of dependency injection and proclaimed it as the way. After that, forget logic, reason and anything remotely resembling independent thought... yeah, you just go ahead and f**k that sh1t because you've got the way. And the way is right and proper and must be used for everything.

print "http://www.codeproject.com".toURL().text Ain't that Groovy?

[moon_stick]

I read an article this week about dependency injection with relation to testing which I thought made some good points; rather than reiterate what was printed, the article's here[^]!

It definitely isn't definatley

[Jeremy Likness]

One problem I see with DI is that a lot of people confuse the framework (Unity, Spring, Windsor, etc) with the concept and pattern. When you are talking about containers and having massive XML configuration files or bootstrappers, etc, you are getting into frameworks and adding a ton of overhead. Sometimes it may be justified. However, DI in and of itself is simple.

public class DataAccessObject
{
private ILogger _logger;

  public DataAccessObject()
  {
     \_logger = LoggerFactory.GetLogger();
  }

  public DataAccessObject(ILogger logger) 
  {
      \_logger = logger;
  }

  public void WriteSomething(string something)
  {
       ...
       \_logger.log(something);
  }

}

This is easy enough to do and no framework required. The "factory" might just return a concrete instance, but by using the factory pattern you can at least change your logger in one place, for example. Adding a framework allows you to put it into a container, and then you can request the object from the container and have the logger injected by the container, etc, but it doesn't always require that level fo complexity. I think the pattern itself lends to solving many problems if you follow Don't Repeat Yourself and Single Responsibility, etc, etc but again, DI as a concept I think is great, whereas the frameworks around it are going to require looking at the flexibility vs. performance and overhead etc etc. It's like choosing a data access strategy between the native SQL client vs. Enterprise Library vs. NHibernate vs. Entity framework, etc ... data access as a pattern obviously is important, HOW you persist your entities depends on more than just saying, "Is saving objects to a database to persist them a good thing?" Jeremy

[zkosior]

Passing interface is a Dependency Injection (property, constructor etc.). If you need to pass small interface than consider Role Interfaces. IoC containers can themselves be small. - bynio

[JasonCordes]

It can be very useful and powerful. And it can allow for configuration of objects that is truly transcendent. Unfortunately, it can be a maintenance nightmare. Trying to track down where, how and why an object is used can be at best difficult and at worst nearly impossible if everything is Injected. Interfaces are the true evil here. While interfaces can be used for good, in my opinion DI uses them for evil. Pure rotten evil. If you have a system of sufficient size (say over 100KLOC), try to avoid DI, it will only cause confusion and delay in the development and more importantly maintenance of your software. I think DI is excellent for prototypes and games, though.

[Jordan Marr]

I'm using Unity container (not the whole CAB) on my current web app and am really enjoying it. My service classes all have a base class that has ICache, IMessaging, ISessionDescriptor, IDataPortal, IExceptionHandler, etc. These are passed into the constructor and resolved by Unity. An interesting one is IMessaging. I have a user control that lives in a master page that is responsible for displaying messsages, validation errors, etc, that implements IMessaging. The user control registers itself via RegisterInstance with Unity. Then when I resolve a service class, the correct instance of IMessaging is automatically resolved, and my service layer can indirectly handle displaying messages & validation errors. Actually, the app uses two different master pages that reference the same messaging user control, but the user control registers itself with Unity, so that is transparent to my service classes, which can rely on the fact that IMessaging will always be available for their use. I also like being about to "resolve" my service classes from the UI layer without without having to construct all this stuff manually. Another plus when resolving a service class is that if any of its pluggable dependencies have their own pluggle dependencies, they will be automatically resolved too. Jordan