Profile’s in StructureMap

This feature has been in StructureMap from the very beginning, but I don’t think that I’ve ever documented it very well.  More docs:

From the very beginning, StructureMap has supported the ability to define a named set of default instances called a "Profile."  The Profile feature was originally meant to be a quick way of switching the connection mode of a smart client application from connected to disconnected modes.  In practice, it’s more commonly used as a way to migrate configuration between environments or for creating alternative deployment configurations.  My team uses the Profile feature in our system as a quick way to collapse our entire distributed application into a single AppDomain for easier testing and debugging.  Our "InMemory" profile is defined like this:

            // Using this Profile configures our application to

            // run completely inside a single AppDomain

            // In production the application will consist

            // of the website and 2-3 external windows

            // services

            var repository = new InMemoryRepository();

            CreateProfile(IN_MEMORY_PROFILE, x =>

            {

                x.For<IRepository>().Use(repository);

                x.For<IEventPublishingService>().Use(new InMemoryEventPublishingService(repository));

                x.For<IUserMessagePublisher>().UseConcreteType<InMemoryUserMessageQueue>();

                x.For<IUnitOfWork>().UseConcreteType<InMemoryUnitOfWork>();

            });

In the code, we can switch the application to the in memory mode by calling the SetDefaultsToProfile() method on the Container (or ObjectFactory.Profile = CoreRegistry.IN_MEMORY_PROFILE):

            // This is actual code from a test harness class we use

            // for integration testing

            IContainer container = createContainer(new RuleSet[]{ruleSet});

            container.SetDefaultsToProfile(CoreRegistry.IN_MEMORY_PROFILE);

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.