DbContext，要注入還是不注入？

Question

這可能是一個有上百萬個答案的問題，但是卻困擾着我很多。

我有一個使用EF的mvc應用程序。 現在將DbContext注入到業務對象中還是以其他方式進行？

我顯然可以注入它，但是那樣一來，我最終在類中使用了DbContext而不是Typed Context。 這意味着我沒有智能感知，代碼看起來不太優美

例如

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時魔鬼本人的工作，因為它有效地將存儲庫模式包裝在一個可笑的存儲庫模式中。 所以這不是我的選擇。

那么我們是否進行注入，如果可以的話，是否可以以某種類型的上下文結束？

還是我們不注射？

Answer 1

首先，我認為“注入”一詞可能會有誤解。

注入意味着：

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：依賴注入的優勢