title: Design - Dependency Hell Solution?
body: <p>We use an MVC architecture with a model consisting of a BLL and DAL. </p>
  
  <p>So we develop "modules" for our system and the particular one I am implementing makes use of alot of the same dependencies. One class in particular has 20 dependencies. Currently the default constructor is creating a default concrete implementation, and we also have a second constructor [that the first one uses] that allows one to inject there own dependencies (i.e. testing.)</p>
  
  <p>20 constructor arguments seems like a pretty nasty code smell.
  The other annoying thing is that often when I starting to add common functionality, I need to go add constructor code and fields in every class often repeating the same kinds of code over and over again.</p>
  
  <p>An IoC container seems like a natural solution to this, but the problem is how far do I go? Do I include the DAL dependencies and the BLL dependencies? What about "helper" or "service" dependencies? It seems like at a certain point I am just recreating the "namespace" structure with the ability to reference my classes like static classes at which point I question what I am actually gaining.</p>
  
  <p>I am having trouble thinking through this. Does anyone have an elegant solution or advice?</p>