除了将所有内容添加到Startup类之外，还有一种健壮的方法来在ASP.NET Core 3.1中注册依赖项吗？

9

我有一个ASP.NET Core 3.1项目。通常，我使用类中的ConfigureServices()方法注册任何依赖Startup.cs项。

但是，我发现自己不得不注册许多依赖项，而且ConfigureServices()看起来很大！我知道我可以创建一个静态方法的扩展方法，并从ConfigureService（）类中调用它，但是想知道是否有更好的方法。

如果有一种方法可以在IoC容器中注册依赖项，而不必一次定义它们

services.AddScoped<Interface, Class>();
.... 200 lines later
services.AddScoped<ISettings, Settings>()

10

将相关依赖项分组到自定义扩展方法中是一种很常见的方法。ASP.NET Core已经为许多内部服务执行了此操作，您可以在此基础上轻松进行扩展，并根据应用程序的需要设置它们。例如，设置身份验证和授权：

public IServiceCollection AddSecurity(this IServiceCollection services)
{
    services.AddAuthentication()
        .AddCookie();

    service.AddAuthorization(options =>
    {
        options.DefaultPolicy = …;
    });

    return services;
}

您可以对特定于应用程序的服务执行相同的操作，并在单独的扩展方法中对其进行逻辑分组。

如果您有很多非常相似的服务注册，则还可以使用基于约定的注册，例如使用Scrutor。例如，这会将某个名称空间中的所有服务注册为它们各自接口的临时服务：

services.Scan(scan => scan
    .FromAssemblyOf<Startup>()
        .AddClasses(c => c.InNamespaces("MyApp.Services"))
            .AsImplementedInterfaces()
            .WithTransientLifetime()
);

Scrutor允许使用非常复杂的规则来扫描服务，因此，如果您的服务确实遵循某种模式，则很可能可以为此制定一个规则。

— 戳
source

3

创建一个自定义属性（称为AutoBindAttribute）

public class AutoBindAttribute : Attribute
{
}

像下面这样使用它（装饰要与[AutroBind]自动绑定的所有实现）

public interface IMyClass {}

[AutoBind]
public class MyClass : IMyClass {}

现在为IServiceCollection创建一个扩展方法

public class ServiceCollectionExtentions
{
    public static void AutoBind(this IServiceCollection source, params Assembly[] assemblies)
    {
       source.Scan(scan => scan.FromAssemblies(assemblies)
        .AddClasses(classes => classes.WithAttribute<AutoBindAttribute>())
        .AsImplementedInterfaces()
        .WithTransientLifetime();
    }
}

现在在Startup.cs中调用它

public class Startup
{

    public void ConfigureServices(IServiceCollection services)
    {
        services.AutoBind(typeof(Startup).Assembly);
    }

}

注意：您可以改善 ServiceCollectionExtentions该类以支持所有范围，例如单例等。本示例仅针对瞬态生命周期显示。

请享用！！！

— 迪尔汗·贾亚西拉克（Dilhan Jayathilake）
source

0

除了提到的。

就个人而言，我喜欢为每个程序集注册一个独立的类。这增加了在正确层使用类的更多控制，并允许使它们成为internalIMO良好的对象。

是否使用scan机制取决于您。有些框架默认提供此功能。依次将相似的依存关系分组在一组类/方法中，应该有助于将解析逻辑保持在一致的位置以进行任何更改。您可以将两种方法结合起来。

— 希姆普
source