c# - 用户作为 ASP Net Core 中的范围服务 - 不好的做法？

Question

在我的 ASP Net Core 应用程序中，我需要经常访问和编辑存储在数据库中的用户相关数据。一般来说，我的方法如下：

• 注入Microsoft.AspNetCore.Components.Authorization.AuthenticationStateProvider可以操作数据的作用域服务（让我们调用该服务UserEditService）
• AuthenticationState从提供的 with中获取当前用户的用户名AuthenticationState.User.Identity.Name
• 注入Microsoft.AspNetCore.Identity.UserManager<AppUser>并使用它按名称从数据库中加载用户。
• AppUser将实例的引用保存在UserEditService
• 操作并保存所述实例

问题是我几乎在我的一些服务中复制并粘贴了相同的代码，我想知道将AppUser对象作为范围服务加载到应用程序中然后将其注入所有服务中是否不是一个更好的主意需要用户访问。我还没有找到人们这样做的项目，这让我觉得这可能是一种不好的做法。是这样吗？如果是这样，为什么？有没有更好的方法来管理 ASPNetCore 中的用户相关数据？

标签： c#asp.net-coredependency-injectionasp.net-identityblazor

Answer 1

由于AppUser由运行时数据组成，尽管当然可以将其注入其消费者的构造函数中，但在对象构造期间注入运行时数据是一些令人不安的缺点。它

导致歧义，使合成根复杂化，承担额外的责任，并使得验证 DI 配置的正确性变得异常困难。相反，让运行时数据流经构造对象图的方法调用。

相反，更喜欢注入一个允许AppUser在运行时检索它的抽象，例如使用如下抽象：

interface IAppUserProvider
{
    AppUser Current { get; }
}

有关缺点的更详细讨论，请查看我的这篇文章。（引用来自那篇文章）

也就是说，尽管这种方法有缺点，但这本身并不会使它成为一种不好的做法或反模式。这是因为有多种方法可以查看运行时数据的使用情况。可以使用两种相互竞争的组合模型；一种是首选将运行时数据捕获到组件中，另一种是首选将运行时数据存储在对象图之外。您可以在此处阅读有关这些竞争模型的更多信息。