DbContext，注入还是不注入？

Question

这可能是一个有上百万个答案的问题，但它让我很困扰。

我有一个使用EF的mvc应用程序。现在，我是将DbContext注入到我的业务对象中，还是采用其他方式呢？

我显然可以注入它，但这样我就可以在我的类中使用DbContext而不是类型化的上下文。这意味着我没有intellisense，代码看起来不那么优雅

例如

var test=(from d in context.Set<User>() where d.Username=="testname" select d).FirstOrDefault();

与键入的可爱相比

var test=(from d in context.Users where d.Username=="testname" select d).FirstOrDefault();

现在我知道这不是一个大问题，但当编写数万行代码时，有intellisense在身边是很好的，特别是如果其他不太熟悉代码的程序员提供帮助的话。

我知道有工作模式的单元，但在我看来，当涉及到EF时，这是魔鬼自己的工作，因为它有效地将存储库模式包装在存储库模式中，这是荒谬的。所以这不是我的选择。

那么我们注入了吗?如果是的话，我们能以某种方式得到一个类型化的上下文吗？

或者我们不注射？

Answer 1

首先，我认为“注入”一词可能存在一些误解。

Inject的意思是：

public class UserService
{
    MyContext _db;

    public UserService(MyContext db)
    {
        _db = db;
    }

    public void GetUserById(string id)
    {
        _db.Users.First(x => x.Id = id);
    } 
}

而不是这样：

public class UserService
{
    MyContext _db = new MyContext();

    public UserService()
    {
    }

    public void GetUserById(string id)
    {
        _db.Users.First(x => x.Id = id);
    } 
}

注意在第一个示例中，MyContext是如何“注入”到构造函数中的。在第二个示例中，UserService本身创建了一个新的MyContext实例。

现在，你应该这样做吗？我认为您应该这样做，事实上，这是一种公认的良好实践。在此之前，请务必阅读并在一些示例项目中尝试它，以了解它给您带来的好处。Wikipidia: Dependency Injection Advantages