Container Ignorance

Posted by Jeremy Miller on February 10, 2008

There’s a pretty good thread on the altdotnet board around AutoMocking Containers and the role of an IoC tool. I’m going to second something that Ayende said: 

…I would say that container ignorance is as important as persistence
ignorance. I don’t want to deal with infrastructure in my code unless I
cannot avoid it.

Ditto from me.  As the guy who’s most likely been using an IoC container in .Net systems for the longest time, minimize your exposure to the IoC container.  It’s infrastructure code.  The classes that do the real work in your system probably shouldn’t have an reference to infrastructure.  Use the heck out of the IoC tool to put together services and object graphs by pushing dependencies into a class, but minimize the number of places where a class has to directly pull something out of the container.  Besides, if you’re leaning hard on autowiring of dependencies, you shouldn’t need that many calls to ObjectFactory.GetInstance().

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://udidahan.weblogs.us Udi Dahan: The Software Simplist

    While I would agree with you (and Oren) in the general case, there are cases where you do need to create objects at runtime – Supervising Controllers creating/opening views as a result of some user action.

    ICustomerView view = this.builder.Build();
    view.Customer = c;
    view.Show();

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Udi,

    Maybe, but I’d rather you do all navigation through a central ApplicationController that can easily track the screen lifecycle. Your code from above inside of a screen Presenter would then be:

    _applicationController.ShowView();

    The real ApplicationController would know about the container, but not the children Presenters.