aspnetcore 注册单例方案

一个单例是没有公共构造函数的，只能通过静态的 Instance 属性获取，这是单例的标准初衷，一个单例是不想让别人调用它的构造函数的。但是 aspnetcore 中提供的 AddSingleton<TService, TImplementation>() ，只提供了类型，而无法注入对象实例，单实例对象还是要框架深层构造的，这实际上并不是安全的做法。

如果使用了标准的单例设计方法，则无法由框架直接生成单实例，这就需要使用点小技巧了。

单例设计

public class Singleton<T> where T : class
{
    protected static T instance;

    protected static object locker = new object();

    public static T Instance
    {
        get
        {
            if (instance == null)
            {
                lock (locker)
                {
                    if (instance == null) //防止线程重入
                    {
                        IEnumerable<ConstructorInfo> constructors = typeof(T).GetTypeInfo().DeclaredConstructors;
                        ConstructorInfo ci = constructors.ToList()[0];
                        instance = ci.Invoke(new object[] { }) as T;
                    }
                }
            }
            return instance;
        }
    }

    protected Singleton()
    {
        IEnumerable<ConstructorInfo> constructors = typeof(T).GetTypeInfo().DeclaredConstructors;
        constructors.ActionForeach(c => {
            if (c.IsPublic)
            {
                throw new InvalidOperationException("禁止从public构造函数中实例化！");
            }
        });
    }

}

以上要点有三个：

1 使用次 if 判断和 locker 保护，防止线程重入时构造多个实例，确保唯一性；

2 在基类中，使用反射调用子类的构造函数完成实例化；

3 基类的构造函数是受保护的，它会检查，禁止子类的公共构造函数调用。

第3条隐藏了一个知识点：子类在初始化实例时，默认会调用基类的构造函数。

因为以上三条机制确保了单例的唯一性，所以反射只会在第一次使用时调用，对性能的影响可以忽略不计。

单例的使用

使用起来非常简单

public class Root:Singleton<Root>
{
    protected Root() { }

    public void DoSomething()
    {
        Console.WriteLine("I feel very happy, cus I'm unique."); 
    } 
}

假设有一个类，叫做Root，由于业务需要，它必须要以单例实现，顾名思义，根只能有一个。

如果不重写 protected 构造函数，则可能发生以下情况：

Root root = new Root(); 

这是被禁止的，万一忘记写了 protected Root(){} 这一行，就会抛出异常，可见在  Singleton<T> 中进行判断，是十分有必要的。

在业务需要的地方，就可以用通常使用的单例模式来调用 ：

Root.Instance.DoSomething();

至此，单例模式完成。

一个真实的业务场景

假设主模块是 Main.dll， 它是一个 aspnetcore 工程， 它调用了 A.dll 作为它的类库。由于某种原因，Root 类必须要在 Main 工程中实现，而不能放到 A 工程中。但是A工程要用到 Root 的方法。如果让 A 工程来引用  Main 工程，这就是反向引用了，这会形成循环引用，是不被允许的。

所以我们可以把 Root 的方法抽象出接口来，注册到 aspnet 框架中，我们可以这样做：

在 A.csproj 中，暴露接口给自己调用：

public interface IRoot
{
    void DoSomething();
}

在 Main.csproj 中实现这个接口：

class Root:Singleton<Root>, IRoot
{
    protected Root() { }

    public void DoSomething()
    {
        Console.WriteLine("I feel very happy, cus I'm unique.");
    }
}

然后就是注册了，在 Main.csproj 工程的 Startup.cs 文件的  ConfigureServices 方法中进行注册：

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllersWithViews();
    services.AddSession();
    //...其他代码
    
　　services.AddSingleton<IRoot, Root>();
}

这样就可以了吗？ no no no ， 这样肯定是不行的，因为前面我们设计的单例，是这样使用的： Root.Instance.DoSomething();  而不是 Root root = new Root(); 

这会导致注入失败，因为框架注册要求 Root 有一个公共无参构造函数，况且它并不知道Root有个静态属性 Instance ，而且只能通过 Instance 来访问。

单例注入方案

下面说到正题了，既然不能直接注册单例，我们可以使用一个中间接口来注入，这个中间接口提供了单例的访问对象，而且它拥有一个没有写出来的默认公共构造方法，它的构造函数，与 Root 类的构造函数，毫无关系，所以可以由框架创建。

在 A.csproj 工程中定义：

public interface IRootProvider
{
    IRoot Root { get; }
}

在 Main.csproj 中实现：

public class RootProvider : IRootProvider
{
    public IRoot Root { get => SomeNamespace.Root.Instance; }
}

然后再注册：

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllersWithViews();
    services.AddSession();
    //...其他代码

    services.AddScoped<IRootProvider, RootProvider>();

    services.AddScoped<ISomeService, SomeService>();

}

look， 我们已经不需要使用 AddSingleton 来注入了，因为  RootProvider 不必是单实例的。

在 A.csproj  中愉快地使用：

public class SomeService:ISomeService
{
    private IRoot root;
    public SomeService(IRootProvider rootProvider)
    {
        this.root = rootProvider.Root;
    }
    
    public void SomeBusiness()
    {
        this.root.DoSomething();
    }
}

SomeService 是在主模块中注入的服务，在主模块中构造，构造的前提是要有一个 IRootProvider 的实例，同时  IRootProvider 要在它的前一行注册，这个很重要。 

到这里，本文就结束了，但我还是想啰嗦一下：

在A中使用的 IRoot root 一点也看不出单例的痕迹，因为 IRoot 只是一个业务接口；同时 IRootProvider 也只提供了 IRoot 的 get 方法， 所以对于 A 模块的开发者，完全不必知道 Root 的存在，更不必知道什么 Singleton<Root> 跟 Instance 的破事。

我们已经完全隐藏了单例模式的实现，这是解决这个问题附带的收获。

这个设计是不是彻底实现了 面向接口编程 的规范？ 快夸我吧！