模型類中的EF上下文

Question

在我們的Web.API項目中，我們使用實體框架6。我們有一個DataModel類，其中包含DatabaseContext。 DataModel是[ThreadStatic]單例。

像這樣：

public class DataModel
{
    [ThreadStatic] private static DataModel _instance;
    public static DataModel Instance => _instance ?? (_instance = new DataModel());

    public DatabaseContext Context { get; private set; }

    private DataModel()
    {
        Context = NewContext();
    }
}

現在，在我們的（部分）模型類之一中，我們使用如下上下文：

public partial class Job
{
    public User CreatedByUser
    {
        get { return DataModel.Instance.Context.Users.FirstOrDefault(d => d.Username == CreatedBy); }
    }
}

我們在數據庫的另一個表中搜索相應的用戶。 這行得通，但我認為這不是一個很好的解決方案。 特別是如果我們計划將項目遷移到.NET Core並將依賴項注入用於數據庫上下文。

我的問題是，是否有一種模式可以更優雅地解決問題？ 依賴注入在這里不起作用，因為Entity Framework會生成模型對象。 還是將代碼從部分類移至util類，會更好嗎？ 但是，我們如何在其中注入上下文呢？

Answer 1

通常，您應該避免要求模型了解其創建和使用上下文，因為該知識應該自上而下而不是自下而上。 除其他原因外，您還會遇到像現在一樣遇到的設計問題。 您可以嘗試在應用程序級別使用擴展方法，控制框架的反轉，實用程序方法，pocos等來圍繞它進行設計，但是最終，您將嘗試解決僅由於您的基礎存在而存在的問題。數據庫架構設計不足，無法滿足您的預期用途。

例如，您的Job表具有對創建它的用戶名的引用。 為什么？ 用戶名可能會更改，並且每當您想要該用戶的其他關鍵屬性時，都需要執行輔助查找（就像您在部分類中所做的那樣）。 如果改為讓Job表維護User表的外鍵，則只要在查詢中包含適當的相關實體，就可以僅使用C＃端的導航屬性來獲取完整的用戶對象。 您甚至不需要局部類，並且作為額外的好處，您的數據庫架構將變得更加易於維護。

有時最好簡化數據庫設計以簡化代碼。