StructureMap partitioning?

I have a set of applications that all use the same basic codebase -- a couple of ASP.NET web projects, some WCF services (running under ASP.NET), a few Windows services and a couple of executables. Most of them are even located in a single Visual Studio solution.

There's a lot of duplication between the various applications as far as injection is concerned. They generally need the same database connections, the same concrete objects, etc.

Because of the duplication, I have a single project called IoC that contains my StructureMap Registry. This is falling apart though as the application requirements diverge.开发者_如何转开发 Some applications do not need to be able to instantiate certain types. Further, this project is becoming a "God Assembly" of sorts with access to nearly every project in the solution.

What's the cleanest way to partition StructureMap injection to provide:

1. Zero code duplication
2. Local variation on a per-project basis

?

I assume you have a "core" assembly that contains a lot of common services, and is referenced by all of your other projects. It can have a StructureMap registry which configures its own services and common configuration values. That should beat most of the duplication problems.

Each additional assembly that provides new services would have its own registry which configures its own services.

Each application would have its own bootstrapper that configures the container with the various registries that it wants to pull in, as well as overrides for any service registration that is specific to that application. This provides the variability per application.

You will have duplication in that every application has its own bootstrapper. But most of the work should be delegated to the various registries. If you think of the bootstrapper like a configuration file, the duplication should be more palatable.