I'm actually wishy washy with DI as well, at first I was pretty damn excited with it, but I suppose it depends on the circumstance and use case. If you're at work and you're pressed on time and budget, you'd need to do some big convincing to show the future benefits.
Furthermore like everyone has said, to sell a feature or a toolset, you really need to nail it at a different perspective, rather than saying DI is awesome, I've used it, it's great for decoupling. Like if you drop subtle problems in the design/architecture of the system that DI can solve, it might communicate your point in a more applicable way. On Thu, Oct 27, 2011 at 7:53 PM, DotNet Dude <[email protected]> wrote: > As others have said try selling it differently...but don't expect > miracles because that's what's needed with some developers. I've run > into a few. If there is true benefit to DI in your project(s) then > push for it but don't get too upset if you don't get your way. > > I'm curious though, how is unit testing happening without at least > some DI? Or are only parts of the system being unit tested and the > rest ignored? > > > On Thu, Oct 27, 2011 at 2:15 PM, Michael Ridland <[email protected]> wrote: > > > > So I've been working with this client for a few years now, all the other > > developers aren't alt.net type. They're older and just love their RAD, > User > > Controls, coming from a dephi background. > > It took me a while but finally I got them doing unit testing, but still > not > > as much as I would like. > > Today I also tried to convince them(the development manager) to > > use dependency injection but he said it was over complicating things and > > it's confusing because you didn't know where the object came from. I > argued > > for decoupling and that objects shouldn't need to know > > where dependences came from or how they were instantiated, objects should > > only worry about their unit of work. > > Am I wrong? > > >
