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().
