これは、ここで説明されているStartup
クラスの背後にある設計原則に関連しています。
https://docs.Microsoft.com/en-us/aspnet/core/fundamentals/startup?view=aspnetcore-2.1
クラスにConfigureServices
やConfigure
などのメソッドを含める必要があることを理解しています。
読みやすくするためにCreateDefaultBuilder(args).UseStartup<Startup>()
が基本クラスまたはインターフェイスを義務付けないのはなぜですか?
この設計アプローチでは、誰かがドキュメントを読み、ConfigureServices
やConfigure
のような魔法のメソッド名について知っている必要があります。
これが新しいクラスの設計マインドセットの一部である場合、それについてどこでもっと読むことができますか?
それがその方法で行われた理由はいくつかあります。より明白な理由の1つは、次のようなConfigure
メソッドにサービスを注入できるためです。
public void Configure(IAppBuilder app, IMyService myService)
{
myService.DoSomething();
}
言うまでもなく、インターフェース、抽象クラス、または継承を使用してこれを行うことはできません。
従来の方法で行われる2つ目の理由は、Configure/ConfigureServices
メソッドだけではなく、環境に依存するconfigureメソッドが無数に存在することです。
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
)。
これは従来のOOP(継承/インターフェイス/抽象クラス)では不可能です。
ミドルウェアやInvoke
メソッドなど、ASP.NET Coreの他の部分にも同じことが当てはまります。 Invoke
メソッドには依存関係を注入することもできますが、次のミドルウェアを呼び出すには、単に
await next?.Invoke();
そして、次のミドルウェアが必要とする依存関係を心配する必要はありません。
完全にするために、Startup
、Configure
、ConfigureServices
という名前のデフォルトのメソッド名(StartupDevelopment
/StartupProduction
)を持つ複数のStartup
クラスを(フォールバックとして)持つこともでき、ASP.NET Coreは環境変数セットに基づいて正しいものを取得します。
スタートアップクラスは、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からの実装でテンプレートファイルを作成しません。なぜそうでないのでしょうか-おそらく間違いか、型付けされていない言語の影響です。