c# - How to use dependency injection in enterprise projects -
imagine have application several hundreds of classes implementing dozens of "high level" interfaces (meaning component level). there recommend way of doing dependecy injection (like unity). should there "general container" can used bootstrapping, accessible singleton? should container passed around, instances can registerinstance? should done registertype somewhere in startup? how can container made accessible when needed. constructor injection seems false, controverse of being standard way, have pass down interfaces component level down used right on startup, or reference hold ending in "know live" antipattern. and: having container "available" may bring developers idea of resolving server components in client context. how avoid that?
any discussion welcome!
edit clarification
i figured out realworld example have better picture of problems see.
lets imagine application hifi system. system has cd player (integrated in cd-rack) , usb port (integrated in usb rack) play music from.
now, cd player , usb port shall able play mp3 music.
i have mp3 decoder somewhere around, injectable.
now start hifi system. there no cd inserted yet , no usb stick pluged in. not need mp3 decoder now.
but constructor injection, have inject dependency cd rack , usb rack.
what if never insert mp3 cd or mp3 usb stick?
shall hold reference in cd rack, when mp3 cd inserted, have decorder on hand? (seems wrong me)
the decoder needed in subsystem of cd rack, started if mp3 gets inserted. have no container in cd rack, constructor injection here?
first of all, dependency injection design pattern not require container. di pattern states:
dependency injection software design pattern allows choice of component made @ run-time rather compile time
take example guice (java dependency injection framework), in java guice di framework not container itself.
most of di tools in .net containers, need populate container in order able inject dependency
i not idea have register every component every time in container, hate that. there several tools auto register components based on conventions, not use unity, can point example ninject or autofac
i writing small utility auto register components based on conventions using practically di tool, still in dev phase
about questions:
should there "general container" can used bootstrapping, accessible singleton?
the answer yes, (there's tool abstract di tool used, called servicelocator) that's how di tools work, there static container available application, however, not recommended use inside domain objects create instances, that's considered anti-pattern
btw have found tool useful register components @ runtime:
http://bootstrapper.codeplex.com/
should container passed around, instances can registerinstance?
no. violate law of demeter. if decide use container better register components when application starts
how can container made accessible when needed
well using common service locator use anywhere in application, said, not recommended use inside domain objects create required instances, instead, inject objects in constructor of object , let di tool automatically inject correct instance.
now based on this:
constructor injection seems false, controverse of being standard way, have pass down interfaces component level down used right on startup, or reference hold ending in "know live" antipattern
makes me think not writing unit tests heavily application bad. suggestion is, before choosing between di tool going use, or before taking answers question consideration, refer following links focus on 1 thing: write clean testable code, far best source answer own question
clean code talks:
http://www.youtube.com/watch?v=wehu57pih5w&feature=player_embedded
http://www.youtube.com/watch?v=rlflcwkxhj0&feature=player_embedded
articles
http://misko.hevery.com/2010/05/26/do-it-yourself-dependency-injection/
previous link in pdf http://misko.hevery.com/attachments/guide-writing%20testable%20code.pdf
the following links super highly recommended
http://misko.hevery.com/2008/09/30/to-new-or-not-to-new/
http://www.loosecouplings.com/2011/01/how-to-write-testable-code-overview.html
Comments
Post a Comment