So what do you think of dependency injection?

[Xiangyang Liu]

Stuart Dootson wrote:

They've always struck me as symptomatic of the "Java way" - if a Java programmer's seen a design pattern they didn't like, it's news to me

Yeah, they also tend to write code that has every possible interface/factory you can think of, but no implementation of anything real.

My .NET Business Application Framework My Home Page My Younger Son & His "PET"

[Jim Crafton]

Roger Wright wrote:

All my dependencies are taken in drink.

You need to write a design pattern that models that. Then, using some of the suggestions under Christopher's thread, market the whole thing to fame and fortune.

¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Oh

[Henry Minute]

Excellent!!

Henry Minute Do not read medical books! You could die of a misprint. - Mark Twain Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.”

[Miszou]

If you want to talk to someone about CAB, Ward Bell[^] is the guy you need to talk to. Make sure you have plenty of time free though, because he is passionate about this stuff and will talk for days if you let him. :-D We've been using the Ideablade[^] DevForce "Classic" framework for a couple of years now and I've met Ward several times at various training sessions. He's a fascinating person to listen to and is very knowledgeable. Personally, I think a lot of the stuff he works on is a bit too academic for most of us in the real world, but it is certainly very interesting and thought-provoking nevertheless.

The StartPage Randomizer - The Windows Cheerleader - Twitter

[peterchen]

I haven't understood why we need frameworks for that, and I am tired of the "how IoC can change your life" four color glossies. Is it really that complex?

Don't attribute to stupidity what can be equally well explained by buerocracy.
My latest article | Linkify!| FoldWithUs! | sighist

[Todd Smith]

I use it in my web projects and find it really useful. You could create a service manager but what about managing the lifetime of objects? That's where IoC really shines imho. The real fun comes from using IoC along with XML configuration so you can change things on the fly. You also have to recode and recompile your service manager anytime a constructor adds or removes a dependency. Another good feature is property injection. If a class needs logging all we have to do is add public ILogger Log {get; set;} and Log gets set by the IoC after construction. No need to change a constructor or worse 50 constructors for a complex hierarchy of objects just to add logging. In a 4teir application web application -> services -> repository -> data access layer what happens when your DAL needs your HttpContext? Are you going to modify every layer to pass along that value? No problemo. Just declare a dependency in the DAL constructor and the IoC will do the rest. Magic! BTW I wouldn't let Microsoft's CAB taint your view of IoC. That CAB is a behemoth. Some say that even after working with it for a year they still haven't grokked it.

Todd Smith

[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