简单来说，使用Ioc模式需要两个步骤，第一是把服务注册到容器中，第二是从容器中获取服务，我们一个一个讨论并演化。这里不会考虑使用如Autofac等第三方的容器来代替默认容器，只是提供一些简单实用的小方法用于简化应用层的开发。
将服务注入到容器
asp.netcore官方给出的在容器中注册服务方法是，要在Startup类的ConfigureServices方法中添加服务，如下所示：
|
1
2
3
4
5
6
7
8
|
public void ConfigureServices(IServiceCollection services)
{
services.AddMvc();
services.AddSingleton(typeof(UserService));
services.AddSingleton(typeof(MsgService));
services.AddSingleton(typeof(OrderService));
}
|
AddMvc方法添加了mvc模块内部用到的一些服务，这个是封装好的，一句话就行了，其他第三方组件也都提供了类似的Add方法，把自己内部需要的服务都封装好注册进去了。但是我们应用开发人员使用的类，还是需要一个一个写进去的，大家最常见的三层架构中的数据访问层和业务逻辑层便是此类服务，上面代码中我加入了三个业务服务类。这显然不是长久之计，我想大家在开发中也会针对此问题做一些处理，这里说下我的，仅供参考吧。
解决方法就是批量注册！说到批量，就需要一个东西来标识一批东西，然后用这一个东西来控制这一批东西。在.net程序的世界中，有两个可选的角色，一个是接口Interface,另一个是特性Attribute。
如果使用接口作为标识来使用，限制就太死板了，一个标识的信息不是绝对的单一，是不推荐使用接口的，因为可能需要引入多个接口才能共同完成，所以我选择特性作为标识。特性相较与接口有什么特点呢？特性在运行时是类的实例，所以可以存储更多的信息。
下面我们简单实现一个AppServiceAttribute:
|
1
2
3
4
5
6
7
|
/// <summary>
/// 标记服务
/// </summary>
[AttributeUsage(AttributeTargets.Class, Inherited = false)]
public class AppServiceAttribute : Attribute
{
}
|
这个特性类取名AppService有两个理由,一是指定是应用层的服务类，二是避免使用Service这样的通用命名和其他类库冲突。
有了标识，就可以批量处理了，我们在一个新的类中给IServiceCollection提供一个扩展方法，用来批量添加标记有AppService特性的服务到容器中。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
public static class AppServiceExtensions
{
/// <summary>
/// 注册应用程序域中所有有AppService特性的服务
/// </summary>
/// <param name="services"></param>
public static void AddAppServices(this IServiceCollection services)
{
foreach (var assembly in AppDomain.CurrentDomain.GetAssemblies())
{
foreach (var type in assembly.GetTypes())
{
var serviceAttribute = type.GetCustomAttribute<AppServiceAttribute>();
if (serviceAttribute != null)
{
services.AddSingleton(type);
}
}
}
}
}
|
我们遍历应用程序中所有程序集，然后嵌套遍历每个程序集中的所有类型，判断类型是否有AppService特性，如果有的话就添加到容器中，这里有点不自信哦，为什么呢，因为我是使用AddSingleton方法以单例模式将服务添加到容器中的，虽然三层中的数据访问层和业务逻辑层绝大部分都可以使用单例，但是我们希望更通用一些，大家都知道netcore自带的Ioc容器支持三种生命周期，所以我们修改AppServiceAttribute，添加一个Lifetime属性：
|
1
2
3
4
5
6
7
8
|
[AttributeUsage(AttributeTargets.Class, Inherited = false)]
public class AppServiceAttribute : Attribute
{
/// <summary>
/// 生命周期
/// </summary>
public ServiceLifetime Lifetime { get; set; } = ServiceLifetime.Singleton;
}
|
Lifetime的默认值我们设置成ServiceLifetime.Singleton是比较合适的，因为大部分服务我们都希望使用单例注册，一个合理的默认设置可以节省使用者很多代码，新手可能还会乐于复制粘贴，但老同志肯定都深有体会。
有了Lifetime这个信息，我们就可以改进AddAppServices方法了，在判断serviceAttribute不为null后，使用下面的代码替换services.AddSingleton(type)：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
switch (serviceAttribute.Lifetime)
{
case ServiceLifetime.Singleton:
services.AddSingleton(serviceType, type);
break;
case ServiceLifetime.Scoped:
services.AddScoped(serviceType, type);
break;
case ServiceLifetime.Transient:
services.AddTransient(serviceType, type);
break;
default:
break;
}
|
现在我们可以注册不同生命周期的服务了，只是该控制是在类的定义中，按理说，服务对象注册到容器中的生命周期，是不应该在类的定义中确定的，因为一个类的定义是独立的，定义好之后，使用者可以用任何一种容器支持的生命周期来注册实例。但是此时这样的设计是比较合理的，因为我们要解决的是应用层服务的批量注册，这类服务一般在定义的时候就已经确定了使用方式，而且很多时候服务的开发者就是该服务的使用者！所以我们可以把这个当成合理的反范式设计。
目前这样子，对于我来说，基本已经够用了，因为在应用层，我都是依赖实现编程的