3.2 组件化启动
📝 模块更新日志
-
其他更改
- 组件
Component模式支持[DependsOn]支持继承 4.8.8.16 ⏱️2023.05.15 #I733RF
- 组件
3.2.1 历史背景
在 .NET Core 2+ 之后,微软推出了 Startup.cs 模式,在这样的模式中,需要任何服务或者中间件处理,只需要在 Startup.cs 文件的两个方法(ConfigureServices 和 Configure)中配置即可。
但在 .NET6 之后,微软不再推荐使用 Startup.cs 模式。
在这里,不阐述 Startup.cs 的优点,就列举几个比较明显的缺点:
- 默认情况下必须放在启动层且主机启动时需通过
.UseStartup<>进行注册,此问题在Furion已解决AppStartup - 配置服务很容易编写出又臭又长的
service.AddXXX()和app.AddXXX()代码,不管是阅读性和灵活性大大减分 - 对服务注册和中间件注册有顺序要求,不同的顺序可能产生不同的效果,甚至出现异常
- 不能实现模块化自动装载注册,添加新的模块需要手动注册,注册又得考虑模块化之间依赖顺序问题
- 不能对模块注册进行监视,比如加载之前,加载失败,加载之后
3.2.2 先看一个例子
在一个大型的 .NET Core 项目中,会经常看到这样的代码:
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
namespace Furion.Web.Core;
public sealed class FurWebCoreStartup : AppStartup
{
public void ConfigureServices(IServiceCollection services)
{
services.AddCorsAccessor();
services.AddControllers().AddInject();
services.AddRemoteRequest();
services.AddEventBus();
services.AddAppLocalization();
services.AddViewEngine();
services.AddSensitiveDetection();
services.AddVirtualFileServer();
services.AddX();
services.AddXX();
services.AddXXX();
services.AddXXXX();
services.AddXXXXX();
services.AddXXXXXX();
// .....
}
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
app.UseHttpsRedirection();
app.UseRouting();
app.UseCorsAccessor();
app.UseAuthentication();
app.UseAuthorization();
app.UseInject();
app.UseX();
app.UseXX();
app.UseXXX();
app.UseXXXX();
app.UseXXXXX();
app.UseXXXXXX();
app.UseEndpoints(endpoints =>
{
endpoints.MapControllers();
});
}
}
可能对于大部分 .NET 开发者来说貌似没有任何问题,但是仔细瞧瞧,这里充斥着大量的 .AddXXXX() 和 .UseXXXX(),真的美观,真的好吗?而且稍有不慎移动了它们的注册顺序可能会引发灾难,还有可能多个服务之间相互依赖,要么全部移除,要么全部保留,未来替代你开发岗位的人知道吗?
试问,这个问题是无解吗?