Почему класс запуска ASP.NET Core не является интерфейсом или абстрактным классом?

Question

Это относится к принципам проектирования, стоящим за классом Startup, описанным здесь:

https://docs.microsoft.com/en-us/aspnet/core/fundamentals/startup?view=aspnetcore-2.1

Я понимаю, что класс должен включать такие методы, как ConfigureServices или Configure.

Почему CreateDefaultBuilder(args).UseStartup<Startup>() не предписывает какой-либо базовый класс или интерфейс для лучшей читаемости?

При таком подходе к проектированию кто-то должен прочитать документацию и узнать имена магических методов, таких как ConfigureServices или Configure.

Если это часть мышления о дизайне нового класса, то где я могу прочитать об этом подробнее?

Answer 1

Класс запуска может быть унаследован от интерфейса IStartup.

// \packages\microsoft.aspnetcore.hosting.abstractions\2.2.0\lib\netstandard2.0\Microsoft.AspNetCore.Hosting.Abstractions.dll
namespace Microsoft.AspNetCore.Hosting
{
 public interface IStartup
  {
   IServiceProvider ConfigureServices(IServiceCollection services);
   void Configure(IApplicationBuilder app);
  }
}

По умолчанию мастер не создает файл шаблона с реализацией из IStartup. Почему бы нет - возможно, ошибка или влияние нетипизированных языков ..

Answer 2

Есть несколько причин, почему это сделано так, как это было сделано. Одна из наиболее очевидных причин заключается в том, что вы можете внедрить службы в метод Configure, такой как

public void Configure(IAppBuilder app, IMyService myService)
{
    myService.DoSomething();
}

Очевидно, что вы не можете сделать это с интерфейсами, абстрактными классами или наследованием.

Вторая причина, по которой это делается традиционным методом, заключается в том, что существует не только Configure/ConfigureServices метод, но и бесконечное число зависящих от среды методов конфигурирования.

public void Configure(IAppBuilder app) { }
public void ConfigureDevelopment(IAppBuilder app) { }
public void ConfigureProduction(IAppBuilder app) { }
public void ConfigureStaging(IAppBuilder app) { }
public void ConfigureSomethingElse(IAppBuilder app) { }

и в зависимости от вашей переменной среды для ASPNET_ENVIRONMENT будет выбран и выполнен другой метод (или по умолчанию Configure/ConfigureServices, если не найдено подходящего для конкретной среды метода).

С традиционным ООП (наследование / интерфейсы / абстрактные классы) все это невозможно.

То же самое относится и к другим частям ядра ASP.NET, таким как Middlewares и метод Invoke. В метод Invoke также могут быть вставлены зависимости, но для вызова следующего промежуточного программного обеспечения вы просто делаете

await next?.Invoke();

и не нужно беспокоиться о том, какие зависимости требуются или могут потребоваться для следующего промежуточного программного обеспечения.

И чтобы быть полным, можно также иметь несколько Startup классов с именами методов по умолчанию (Configure / ConfigureServices) с именами StartupDevelopment, StartupProduction, Startup (как запасной вариант) и ASP. NET Core подберет правильный, основанный на наборе переменных среды.