我开发了一个包含大量 razor 页面
的 C# ASP.NET Core MVC
应用。
我的大多数 razor 页面都使用日志记录、发送电子邮件并使用多个数据库上下文。
很多类看起来像这样:
class A : PageModel
{
private readonly ADbContext _context;
private readonly UserManager<ApplicationUser> _userManager;
private readonly IEmailSender _emailSender;
private readonly ILogger<MyModel> _logger;
public UpdateModel(ADbContext context,
UserManager<ApplicationUser> userManager,
IEmailSender emailSender,
ILogger<MyModel> logger)
{
_context = context;
_userManager = userManager;
_emailSender = emailSender;
_logger = logger;
}
}
我有 10 多个这样的页面。 当我创建页面时,我必须添加这些字段。所以很多次。
摆脱大量字段声明的理想方法是什么?继承我开发的每个页面模型的基类
?但这个基类将是一个非常通用的基类,具有日志记录、电子邮件和上下文,但彼此之间并不相似。
每次声明使用这些字段的类时都声明这些字段是一个很好的架构选择吗?
最佳答案
总的来说,是的,这就是你所做的。您的依赖项正在被注入(inject),这意味着您需要 ivars 来保存它们,并需要一个构造函数来接受它们。它可能感觉和看起来重复,但实际上是一件好事。它使您的类一目了然:您可以一目了然地快速了解该类具有哪些依赖项。
如果您愿意,您可以创建一个基类。但是,您应该小心,只在您的基础类中包含真正适用于每个派生的内容。危险在于添加在所有情况下实际上都不需要的依赖项,然后现在您有一堆页面加载它们不需要且不使用的依赖项。
您还可以在此处使用某种程度的抽象。例如,如果每个页面都依赖于一个上下文,但不同场景下可能有不同的上下文,则可以将 ivar 输入为 DbContext
,而不是具体的上下文类型,然后您可以将其设置为 DbContext
的任何有效派生。您的记录器也是如此。你实际上想注入(inject) ILogger<MyPageModel>
,但您可以将基类上的 ivar 设置为 ILogger
,然后它将接受任何记录器。
不过,当你开始这样做时,你会更难弄清楚类的依赖关系,所以这是一个让步。就我个人而言,我只会使用共享逻辑的基类(如果存在)。如果基类的唯一目的是定义一组特定的依赖项,那么它就不值得拥有。
关于c# - 通过依赖注入(inject)获取 dbcontexts 背后的 10 多个 razor 页面代码,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/57081498/