The factory pattern is not mutex with the DI pattern. You don’t have to use the DI container to instantiate everything. I like to think of the concepts of “services” within your application, and these things are great examples of when to use a DI container. A canonical example is the logger. You do logging in your app, so you can think of logging as a “service” that is consumed by other classes. Your classes can have a constructor that calls for an instance of ILogger. Now, your data transfer objects, your view models, stuff like that, they’re not really good candidates for construction by the DI container. If you have a service that returns instances of “people” objects, you can still use your traditional methods for creating sets of models, use your polymorphic patterns as you needed to model the problem domain.

Another example, I have a project that I’m working on that has a set of services that handle data access, abstracting away the differences between Oracle and SQL Server and drivers and all that stuff. I consider that a “service” that’s used by pretty much any class that needs to talk to a database. The DI container supplies the correctly configured instances of the data builder classes to classes that depend on them. These classes use the data services, but they build the data transfer objects the usual way. So the idea is to use what makes sense in a particular situation. Eventually it’ll be second nature, you’ll find yourself newing up a class, and it’ll just *feel* wrong, you’ll get the sense that something else should handle construction and lifetime, and you just need to use a service. That’s where you use DI.

Thanks for the comments, and happy coding

By calling:

var dal = Container.Resolve();

in the boot strapper, are you loading the entire object graph into memory at the outset? wouldn’t the container immediately resolve all its dependencies (i.e. the whole graph)? If that is so, then how how do you manage conditionally created objects/polymorphic objects that would have more traditionally been supplied using a factory pattern, and only instantiated on demand. Or do you drop the purist dependency approach and inject factories into your callstack.

Thanks in advance for your assistance.