在.net core中实现字段和属性注入的示例代码

简单来说，使用Ioc模式需要两个步骤，第一是把服务注册到容器中，第二是从容器中获取服务，我们一个一个讨论并演化。这里不会考虑使用如Autofac等第三方的容器来代替默认容器，只是提供一些简单实用的小方法用于简化应用层的开发。

将服务注入到容器

asp.netcore官方给出的在容器中注册服务方法是，要在Startup类的ConfigureServices方法中添加服务，如下所示：

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:

/// <summary> /// 标记服务 /// </summary> [AttributeUsage(AttributeTargets.Class, Inherited = false)] public class AppServiceAttribute : Attribute { }

这个特性类取名AppService有两个理由,一是指定是应用层的服务类，二是避免使用Service这样的通用命名和其他类库冲突。

有了标识，就可以批量处理了，我们在一个新的类中给IServiceCollection提供一个扩展方法，用来批量添加标记有AppService特性的服务到容器中。

public static class AppServiceExtensions { /// <summary> /// 注册应用程序域中所有有AppService特性的服务 /// </summary> /// <param></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属性：

[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)：

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; }

现在我们可以注册不同生命周期的服务了，只是该控制是在类的定义中，按理说，服务对象注册到容器中的生命周期，是不应该在类的定义中确定的，因为一个类的定义是独立的，定义好之后，使用者可以用任何一种容器支持的生命周期来注册实例。但是此时这样的设计是比较合理的，因为我们要解决的是应用层服务的批量注册，这类服务一般在定义的时候就已经确定了使用方式，而且很多时候服务的开发者就是该服务的使用者！所以我们可以把这个当成合理的反范式设计。

目前这样子，对于我来说，基本已经够用了，因为在应用层，我都是依赖实现编程的😀（哈哈，会不会很多人说咦......呢？）。设计模式说：“要依赖于抽象,不要依赖于具体”，这点我还没做到，我抽空检讨（呵呵，谁信呢！）。所以呢，我们的批量注入要支持那些优秀的同学。

从上面的代码不难发现，如果定义接口IA和其实现A:IA,并在A上添加AppService特性是不行的：

public interface IA { } [AppService] public class A : IA { }

这个时候我们并不能依赖IA编程，因为我们注册的服务类是A，实现类是A，我们需要注册成服务类是IA，实现类是A才可：

public class HomeController : Controller { private IA a; public HomeController(IA a) { this.a = a; //这里a是null,不能使用 } }

让我继续改进，在AppServiceAttribute中，我们加入服务类型的信息：

[AttributeUsage(AttributeTargets.Class, Inherited = false)] public class AppServiceAttribute : Attribute { /// <summary> /// 生命周期 /// </summary> public ServiceLifetime Lifetime { get; set; } = ServiceLifetime.Singleton; /// <summary> /// 指定服务类型 /// </summary> public Type ServiceType { get; set; } /// <summary> /// 是否可以从第一个接口获取服务类型 /// </summary> public bool InterfaceServiceType { get; set; } = true; }

我们从两个方面入手来解决服务类型的问题，一个是指定ServiceType，这个就毫无疑问了，在A的AppService中可以明确指定IA为其服务类：

[AppService(ServiceType = typeof(IA))] public class A : IA { }

（编辑：衡阳站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!