I think my examples are probably more confusing than they should be. if you develop your layers without thinking about the DI layer, just rely on getting dependencies into objects via a constructor, you can add the DI container later. Typically the container would resolve the controller (transparent to your code) and inject an instance of a factory, or repository, or service.. or whatever is needed Then in the example of the IOrderFactory, the create could also be implemented to resolve the Order object from the same container But, if the Order is an Entity you should be using a IOrderRepository to manipulate it, and this can include the factory method Create() The key is to not architect your layers with the DI container in mind, just use the right sort of services to get the job done, at the end of the day they *might* be implemented using a DI container, they might not... if you working with this sort of technology your probably trying to unit test too, so if you get this right, it will probably lead you down the right path anyway. Google sturcture map ASP.NET MVC implementation there are some good articles that demonstrate the idea behind a simple DI container and MVC. Good luck James
James Simpson Web Solutions Developer www.methodworx.com