public interface IMyInputProviderPlugin
{
IMyOutput Provide(IMyInput data);
}
This is an interface I need to provide so that I can dynamically load the dlls and not have them bound to my implementation.
However, upon reading this, it seems like this is an anti-pattern?
http://blog.ploeh.dk/2011/04/27/Providerisnotapattern/
I'm confused, how does one do this if not this way?
Every pattern attempts to solve one or more challenges in software design, and has a set of disadvantages. You will need to study the patterns that you can utilize in your situation and determine what suits your needs the best.
The link you shared in your question is by Mark Seeman whose book that he references in the article is primarily focused on Dependency Injection (DI). DI forces many design principles and has many advantages, and thus there are many DI containers developed in various languages that can be utilized for DI. DI container lets one apply DI more easily and a typical DI container will do lifecycle management of the various types including instantiating those. If you used DI containers, it is likely that you would not need to use the provider model.
However, in my personal experience, there are situations where one does not use a DI container and the code needs to locate a service and use it (pretty much like what you are planning to do). This pattern is called service locator pattern, and provider model can be argued to be a specialization of that design pattern. Thus, you will see that there are developers who will disagree with Mark Seeman. (FYI, read the comments if possible of both articles for disagreements).
Eventually, it comes down to you determining what suits your needs the best. I have used dependency injection as well as something similar to the provider model, and they both serve certain needs and in some cases, one is preferable over the other. For example, if I had to provide the ability of my running application to be able to load another externally provided module and manage its lifecycle without shutting the main application down, I am quite likely to go with the provider model, and will typically end up writing custom code to exert complete control over the interfaces.
IMO, you should weight the pros and cons of each approach (perhaps even prototype if needed), and go with what is most likely to work with you instead of delving too much into the question of whether it is a "pattern" or "anti-pattern".
