DbContext，注入还是不注入？

这可能是一个有100万个答案的问题，但它让我感到非常困扰。DbContext，注入还是不注入？

我有一个使用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();

现在我知道这是不是一个巨大的问题，但书写时数数以千计的线路，很高兴有智能感知，特别是如果其他编码人员不太熟悉的代码帮助。

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

那么，我们注入，如果是的话，我们可以以某种方式结束了一个类型化的上下文？

或者我们不注射？

来源

2015-11-03 coolblue2000

不知道你有什么问题。如果你使用代码生成的dbcontext代码，你应该有.Users。 – Kelmen

是的，如第二个例子。但是，如果使用注入，则必须使用DbContext基类，而不是它们生成的基类。 – coolblue2000

请检查这篇文章：http://mehdi.me/ambient-dbcontext-in-ef6 –

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

进样含义：

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

来源

2015-11-03 05:21:52 hatcyl

对不起，是的，我知道什么是注射（虽然我应该明确）。然而，注入导致必须使用基类或接口（否则将会是什么意思？），因此我的问题。 – coolblue2000

@ coolblue2000啊，我看到问题了。不，'注射'并不意味着使用基类。你可以注入你的'输入'上下文没有问题。更大的谈话是'我们应该依靠具体还是抽象？'这是一个更难的问题：P – hatcyl

是的，虽然有可能注入一个具体类型，但是注意什么是没有比简单地将具体类型定义为非注入依赖关系更好的...... – coolblue2000

DbContext，注入还是不注入？

回答

相关问题