Runtime configuration vs Designtime configuration

Jun 16, 2011 at 9:45 AM

Hi all,

Need your help in understanding when to use Run-time Config vs Design-time. I can only think of following factors which might affect this decision.

1. My understanding is that we need to write code in Run-time Config so any changes to dependencies means re-compile application (Pls correct me if I'm wrong) 

2. Run-time config defers the decision of which dependency should be injected till runtime so it can be programmed. – But need real example where design time can't be used.

3. I’m guessing performance of Design-time should be better than Run-time (Please correct me if I’m wrong)

Please share your thoughts.


Jun 16, 2011 at 10:20 AM

Found the answer to my question here -

Thanks for reading though!

Jul 5, 2011 at 1:56 PM

From my past experiences I have found trying to keep an XML configuration file with the interface to concrete type mappings require too much maintenance.  Also if you are working in a multiple developer environment, all users will have to make sure they keep the file updated and have the latest version.  In prior projects have found that the only reason to specify various implementations of a given contract type would be to have specific concrete classes for unit-testing.  However, it is best that unit-test coded have no dependencies on a DI container such as Unity.  Given this, I design my business components and repositories so they can be easily unit-tested by having them expose all dependencies via constructor parameters.  For example:

Assume you have:


When unit testing, a mock version of the payment repository would be referenced and passed to the business component with know data:

MockPaymentRepository paymentRepository = new MockPaymentRepository( new List<Payment> { new Payment{ Amount = 30 }, new Payment { Amount = 50 } }  );
PaymentComponent component = new PaymentComponent(paymentRepository);
Assert.AreEqual(80, component.Total);

But when the application executes, it uses Unity to glue all of the components together so the actual implementations are used.  Still, having to have to maintain the XML can require many entries that typically follow some type of pattern.  For example, all repositories implement an interface named IRepository or a typed version IRepository<>.  All business components have an interface and concrete type that have a similar naming conventions:  IPaymentComponent and PaymentComponent.

Given this what I do in my new code implementations is to use reflection to search a given list of assembles for these common conventions and configure the unity container automatically.  So in the end, all a developer has to do is add and interfaces and classes that match the known conventions and Unity is automatically configured without any messy XML configurations.  There is an open source project out there that provides sevices for doing this but I decided to use reflection since it is non-DI container specific.

Hope this information helps some.



Jul 7, 2011 at 6:25 AM

Thanks a lot Brian for great reply.

Is it possible for you to provide the sample code for reflection mechanism you mentioned?

Thanks again,


Jul 7, 2011 at 4:16 PM

I have code that is part of a larger solution.  But below is code that will scan a list of assemblies for classes that match a given name.  When it finds a class that matches a given pattern, it finds the interface on the class that matches the same pattern.  If it finds such an interface, it then registers the found class for the found interface.  Note that this scanning and building of the unity container is only done once on application start up.    Below is the code that plugs into my overall architecture.  Basically I have another component that knows about a list of IAsseblyTypeRegistry implementations (specified on application start-up).  Below I am showing just one but you can implement others to discover types based on any type of information found using reflection.  The outer code processes each IAssemblyTypeRegistry entry and invokes the RegisterTypes on each listed register after it creates an unity container.  The container is passed to the RegisterTypes method (note I am passing a class called FactoryConfiguredComponent but that is part of my architecture and you can simply pass IUnityContiner.  So I have the below implementation of IAssemblyTypeRegistry and also have ones that are specific to my architecture such as one that finds all classes that implement IRepository and another one that finds all Entity Framework context types and it registers an unit-of-work class that wraps the context.  But they all follow the below pattern.  Eventually in my outer class, I will have very detailed logging that will write out all the discovered classes and interfaces that were registered with Unity. 


public class MatchedNameTypeRegistry : IAssemblyTypeRegistry
        public string[] ScanAssemblyNames { get; private set; }
        private string nameToMatch = null;

        public MatchedNameTypeRegistry(string nameToMatch, params string[] scanAssemblyNames)
            this.nameToMatch = nameToMatch;
            this.ScanAssemblyNames = scanAssemblyNames;

        public void RegisterTypes(FactoryConfiguredComponent factory, IEnumerable<Type> types)
            foreach (Type matchedType in FindMatchingConcreteClasses(types))
                Type matchedInterface = FindMatchingInteface(matchedType);

                if (matchedInterface != null)
                    factory.RegisterType(matchedInterface, matchedType);

        private IEnumerable<Type> FindMatchingConcreteClasses(IEnumerable<Type> types)
            return types.Where(t =>
                 t.IsClass &&
                !t.IsAbstract &&

        private Type FindMatchingInteface(Type type)
            var results = type.GetInterfaces().Where(ri =>
                !ri.IsGenericType &&

            return results.Count() == 1 ? results.First() : null;

So in my application start-up code I have something like the following:
            // Business Components
            AddAssemblyTypeRegistry(new MatchedNameTypeRegistry("BusinessComponent", "RefArch.Business.Components"));
            AddAssemblyTypeRegistry(new MatchedNameTypeRegistry("BusinessProcessController", "RefArch.Business.Components"));
            AddAssemblyTypeRegistry(new MatchedNameTypeRegistry("Component", "RefArch.Patterns.Accounting"));

Hope this code helps some in how I approached configuring unity.


Jul 8, 2011 at 5:16 AM
Edited Jul 8, 2011 at 5:18 AM

Thanks Brian. Sure this will help !

If I'm not wrong, this is called AutoWiring - correct?

Jul 8, 2011 at 11:37 AM

Yes.  Some DI containers have this type of functionality built in and call it scanning.  But I like using the reflection API since it is generic and not specific to any container.  Also you can search for types based on almost any type of search criteria without being limited to what a given container may or may not provide.