Unity DI Composition Root vs XML I'm having trouble figuring out the best approach with DI. After doing more research, Mark Seeman recommends using the Composition Root approach. In my example, I am using XML configuration to design my mappings which allows me to drop any new dll that implements an interface without having to perform a build on the whole solution. If I use a composition root, doesn't it become a violation of Liskov's principle since I have to manually make changes and then perform a rebuild?

Here is a link to my GitHub project

Interface Shared By all Projects

namespace UnityRnD.Core
{
    public interface IGreeting
    {
        string GetGreeting();
    }
}


Main Application

namespace UnityRnD.Application
{
    class Program
    {
        private static void Main(string[] args)
        {


            var section = (UnityConfigurationSection)ConfigurationManager.GetSection("unitySingleNamed");
            IUnityContainer container = new UnityContainer();
            container.LoadConfiguration(section);

            var letsTalk = container.Resolve&lt;IGreeting&gt;("tom");
            Console.WriteLine(letsTalk.GetGreeting());
        }
    }
}


The Plan

The plan is to create a bunch of projects that represent a Line of Business. Each project will have a class that implements IGreeting. I can then drop that library into the bin and add a Unity config setting to point to that project. On the resolve where it says "tom" this can become a variable which will remove that hard reference to the string "tom."

Stacey and Tom projects

namespace UnityRnD.Tom
{
    public class Greetings : IGreeting
    {
        public string GetGreeting()
        {
            return "Hi, my name is Tom.";
        }
    }
}


Michael Project
notice the class name changes.

namespace UnityRnD.Michael
{
    public class ChattyKathy : IGreeting
    {
        public string GetGreeting()
        {
            return "Hi I'm Mike and I like pizza. Lets talk about pizza for a moment.";
        }
    }
}


I'm looking for help on whether to create a new project for a Composition Root to hold all the references.  Does the main application need hard references to all of them, or does using the XML configuration suffice?
The composition root is just the place in your code where you'll compose the application and resolve the entire dependency graph at once. You'll want that as close as possible to the application's entry point - the Main method is perfect for this in a console application.

Regardless of your IoC container, the first thing you need to do, is to configure it - to tell it what implementation to supply for the constructor-requested interfaces.

That's the key right here: constructor injection. Your IoC container is the object responsible for owning the instances of everything under its wing. The resolution phase resolves services, with their own dependencies; you don't resolve a string, you resolve an interface that presents a string.

Your entire program lives and dies inside the Main method - your example is too trivial to demonstrate the benefits of DI/IoC, I don't think it's a good example.

Imagine you have a data layer, a business layer and a presentation layer. In a non-IoC code base the BLL will have a dependency on the DAL, and will consume its API; the presentation layer will probably run the show, and have a dependency on the BLL.

With IoC you revert the dependencies. The BLL doesn't need to know about a DAL. Instead the DAL has a dependency on the BLL, and it implements the interfaces that the BLL is coded against.

The presentation layer is the logical place to compose the application, if your application's entry point is typically right there.

The composer assembly needs to have references to all the assemblies that basically provide the implementations - nothing forbids creating a separate assembly just for wiring up the application and starting it.



If the composition root is in its own assembly, it's all you need to recompile. I like defining my mappings with code, because I get IntelliSense and compile-time validity.

Unfortunately there's not much code to review in your question, ...we can't review what you haven't written yet! Good luck!

Please come back when you've implemented a functionality, right now I don't think your project isn't ready for peer review.

(cough) that was too long for a comment ;)