前言

Blazor 具有前后端不分离模式，但是如何直接调用需要一定的设置

Blazor 依赖注入

依赖注入在spring里面很常见，毕竟.NET 是个巨型融合怪。只要你这个好用我就抄。我还是很佩服的，能实现就行，谁管是谁第一个开发的。MVVM还是WPF首创的呢，Vue用也没关系。能简化程序员逻辑就行。

依赖注入用于解决什么问题？

依赖注入解决了两个问题

代码解耦
- 使用先存后拿的形式，我们使用的时候直接拿依赖对象，不需要知道依赖对象是怎么来的。
生命周期
- 如果解耦问题只是为了程序写起来舒不舒服。那么生命周期就是代码的功能问题。

下面重点讲解生命周期

依赖注入的生命周期。

微软官方文档依赖注入生命周期
asp.net core 依赖注入
AddSingleton的生命周期：项目启动-项目关闭相当于静态类只会有一个
AddScoped的生命周期：请求开始-请求结束在这次请求中获取的对象都是同一个
AddTransient的生命周期：请求获取-（GC回收-主动释放）每一次获取的对象都不是同一个

根据我实际测试得到如下结果。

Singleton：单列
- 生命周期：程序
- 程序启动时注册，程序结束时销毁
- 一般不用，因为每个网页共用的情况很少
Scoped：范围
- 生命周期：网页
- 网页打开时注册，网页刷新时销毁
- 两个相同地址的网页依赖对象互补干扰，即每个网页对象唯一
- 使用频率最高，和浏览器缓存搭配使用，相当于全局静态变量
Transient：瞬时
- 生命周期：路由
- 路由不动时存在，路由移动时销毁
- 即从index/a 调到index/b再跳回index/a就销毁了。
- 使用频率较低，相当于临时变量，不如直接声明临时变量。

那么根据实际情况，我们还需要加一个。生命周期：浏览器。那么就要用到浏览器缓存了。因为我们不希望用户一刷新网页就跳到登录页面了，还是要和浏览器绑定。

行为	算不算网页刷新
刷新网页	算
页面点击的路由跳转	不算
在网页手动输入的页面跳转	算

测试代码

服务类

    public class TestModel{public  int count { get; set; } = 0;public  int AddCount(){count++;return count;}}

Blazor点击网页

@using BlazorApp2.Data
@inject TestModel TestService<PageTitle>Counter</PageTitle><h1>Counter</h1><p role="status">Current count: @currentCount</p>
<p>Static count : @StaticCount </p><button class="btn btn-primary" @onclick="IncrementCount">Click me</button>@code {private int currentCount = 0;private int StaticCount = 0;private void IncrementCount(){currentCount++;StaticCount = TestService.AddCount();//Console.WriteLine("打印"+currentCount);}
}

在App.razor里面注册

            builder.Services.AddSingleton<TestModel>();builder.Services.AddScoped<TestModel>();builder.Services.AddTransient<TestModel>();

总结

一般来说，大部分时候都是Scoped(范围)来绑定整个页面，再用Cookie让登录不登出页面。

补充

日期2023年8月4日

我看了一下别人的写法
.Net Core WebApi Redis消息订阅

在这里插入图片描述
我觉得他说的很有道理。
Singleton非常容易内存泄漏，基本不用。
Scoped会在每次页面刷新的时候重新注入依赖。会将依赖注入初始化。用户使用不稳定，用来跨页面传值不稳定。
Transient虽然会在每次路由跳转的时候消失，但是反而是最稳定的。因为页面刷新和路由跳转都是一样的。反而不容易出Bug。