.net core 3.1 - 一般问题/设计问题[关闭]

Question

首先，让我先说我绝不是一名专业的编码员，而且由于我已经在不同的领域工作了很多年，所以我现在才重新开始为我的业余项目编码有。我每个 ado.net 的旧项目（带有存储过程的 ms sql）、web 表单、很少的 mvc/etc。

过去，我会创建这样的类：

public class blah
{
    public int Id;
    //more properties

    public static Get(id){ //call db class here, get row, use linq to convert to object }
}

现在，使用 .net 核心，这被认为是“糟糕的”。我正在学习 EF，虽然我可以使用 DI..我只是觉得拥有 DI 链很麻烦。即：我不能只使用默认构造函数创建类的实例。我现在必须传入 DI。为此，我需要将 DI 链接到控制器，并且 w/e 子类可能需要使用指定的类。默认情况下，在我的 startup.cs 中，我有所需的代码：

services.AddDbContext<ApplicationDbContext>(options =>
                options.UseSqlServer(
                    Configuration.GetConnectionString("DefaultConnection")));

现在，在我的课程中，我不能只调用 ApplicationDbContext()...因为它必须使用 DI 来获取连接字符串。所以我把它链接起来，所以这个类现在看起来像这样：

public class blah
{
    public int Id;
    //more properties
    private ApplicationDbContext _context;
    public blah(ApplicationDbContext dbContext)
    {
         _context = dbContext;
    }

    public static Get(id){ //use EF here to get the object }
}

这会导致另一个问题，即现在我无法执行“blah myBlah = blah();”如果我只想创建一个类的实例。 W/e 我调用它，再次必须有 DI。

我错过了什么吗？我读过 ServiceLocators/etc 是不好的（反模式），应该避免。
请注意，我不仅使用“控制器”，而且还试图找出 Razor 页面/whatnot 适合的位置。

Answer 1

使任意创建对象变得困难或不可能是 DI 的一个副作用，也是一个很好的副作用。执行此操作的代码模块极难测试，因为它的依赖项隐含在该代码中。相反，预先明确指定其依赖项的模块很容易测试，因为您可以模拟或存根这些依赖项以做尽可能少的事情，以确保您正在测试的只是那个模块 .

强迫你明确你的依赖关系迫使你思考你的代码是如何设计的。这会导致代码设计得更好。

最后，更务实一点，如果您使用的是 DI 框架，为什么不依赖它来完成现有的工作 - 创建和注入您的依赖项？你为什么要解决它？

至于服务定位器，也许您想重新阅读您声称已阅读的内容。我想您会发现他们声明显式使用服务定位器通常是一种反模式 - 但 ASP.NET Core DI 是隐式的。