views:

19

answers:

1

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

?

A: 

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.

Joshua Flanagan
This approach means that StructureMap has to be referenced by every assembly. I was avoiding that, but I can revisit that decision.
roufamatic
Also, I hate configuration file duplication as well. :-)
roufamatic
Ok, if your library assemblies are not already referencing StructureMap, dont start now. Instead, keep the registries in your application assemblies.
Joshua Flanagan
You might also investigate establishing conventions in your codebase so that you do not need so much explicit configuration. A single registry should be able to say "scan all of the assemblies in the app folder and register instances using the default naming convention". The only explicit registration should be for your db connection and any singletons, etc.
Joshua Flanagan