IoC 优于我的工厂单例

在使用单例方面似乎存在污名。我个人从未购买过它，但为了思想开放，我试图尝试 IoC 概念作为替代方案，因为坦率地说，我对日常工作感到厌倦，想尝试一些不同的东西。如果我对 IoC 概念的解释不正确或被误导，请原谅我。

情况是这样的：我正在Windows服务中构建一个简单的基于HttpListener的Web服务器，该服务器利用插件模型来确定应如何根据请求的URL处理请求(就像其他询问HttpListener的其他人一样(。我发现插件的方法是在配置的目录中查询用HttpModuleAssemblyAttribute修饰的程序集。这些程序集可以包含 0 个或多个IHttpModule子程序集，此外，这些子程序集还使用用于指定模块名称、版本、人类可读说明和各种其他信息的HttpModuleAttribute进行修饰。像这样：

[HttpModule(/*Some property values that matter */)]
public class SimpleHttpModule : IHttpModule
{
    public void Execute(HttpListenerContext context)
    {
        /* Do Something Special */
    }
}

当发现HttpModule时，我通常会将其添加到Dictionary<string, Type>对象中，该对象的唯一目的是跟踪我们知道哪些模块。这本词典通常存在于我的各种单例中，它具有ACE风格单例的角色(这是我C++岁时了解单例的遗产(。

现在我正在尝试实现的是使用(我对(一般 IoC 概念的类似内容。基本上我有一个AppService集合，其中IAppService定义为：

public interface IAppService : IDisposable
{
    void Initialize();
}

我的插件AppService看起来像这样：

[AppService("Plugins")]
internal class PluginAppService : IAppService, IDictionary<string, Type>
{
    /* Common IDictionary Implementation consisting of something like: */
    internal Type Item(string modName)
    {
        Type modType;
        if (!this.TryGetValue(modName, out modType)
            return null;
        return modType;
    }
    internal void Initialize()
    {
        // Find internal and external plug-ins and add them to myself
    }
    // IDisposable clean up method that attempts to dispose all known plug-ins
}

然后在服务期间OnStart我实例化了一个本地已知但传递给所有实例化插件的构造函数的 AppServices 实例：

public class AppServices : IDisposable, IDictionary<string, IAppService>
{
    /* Simple implementation of IDictionary */
    public void Initialization()
    {
        // Find internal IAppService implementations, instantiate them (passing this as a constructor parameter), initialize them and add them to this.
        // Somewhere in there would be something like
        Add(appSvcName, appSvc);
    }
}

我们曾经的单一方法实现变成了子级上的抽象实现+构造函数：

[HttpModule(/*Some property values that matter */)]
public abstract class HttpModule : IHttpModule
{
    protected AppServices appServices = null;
    public HttpModule(AppServices services)
    {
        appServices = services;
    }            
    public abstract void Execute(HttpListenerContext context);
}
[HttpModule(/*Some property values that matter */)]
public class SimpleHttpModule : HttpModule
{
    public SimpleHttpModule(AppServices services) : base(services) { }
    public override void Execute(HttpListenerContext context)
    {
        /* Do Something Special */
    }
}

对常用应用程序服务的任何访问都变为：

var plugType = appServices["Plugins"][plugName];

而不是：

var plugType = PluginManager.Instance[plugName];

我在这里是否缺少一些基本的 IoC 概念来简化这一切，或者所有这些附加代码真的有好处吗？在我的世界里，单例是简单的生物，它允许整个程序中的代码访问所需的(相对静态的(信息(在这种情况下是类型(。

更明确地提出问题：

1. 这是转换为 IoC/DI 概念的工厂单例的有效实现吗？
2. 如果是，所需的额外代码和强加看似更笨拙的 API 的回报/好处在哪里？