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 的破事。

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

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

 

posted @ 2020-08-24 19:52  滴水有灵  阅读(1221)  评论(1编辑  收藏  举报