1

I love IoC mostly for its tooling to help with testing, particularly with tools like Moq. I want to employ these testing practices I have picked up over the years in a public library that 3rd party developers will use, however I am unsure on how to make the library consumable.

I have taken on the practice of using factories for my instantiation, which is a pattern that has worked well for past projects, but given that I was in control of the application, I could use the same container for the full application.

As I want to provide services from my library without direct instantiation via new, or have my application consumers use my container, I am unsure as to how I can make this a smooth process.

One theory was to create public static methods that wrap a resolved factory;

public static class MyObjectProvider
{
    public static IMyObject CreateSomeObject(//args)
    {
        return Container.Resolve<IMyObjectFactory>().Create(//args);
    }
}

whereby Container is an internal static reference. Although this is in essence a service locator pattern, I can't think of any way to go about it. With this the chain will be resolved by constructor injection, and the standard fare would apply herein.

Daniel Park
  • 3,903
  • 4
  • 23
  • 38
  • 3
    Read this: http://blog.ploeh.dk/2014/05/19/di-friendly-library/ – Steven Mar 04 '15 at 13:11
  • 2
    At first, I was not understanding the principle of this at all. I was stuck in the mindset that the library itself had to implement the DI container. Now that I have spent some time designing everything out (via interfaces of course) it dawned on me that I need to keep the library free and open for use of any container. But for those not wanting to use it, provide activators with default values. If they want to change things, simply access the more open constructor. – Daniel Park Mar 08 '15 at 12:36

0 Answers0