我可以像使用 LINQ 到 SQL 一樣使用實體框架嗎？

Question

我已經開始嘗試使用 LINQ 到 SQL 並且我正在做的基本上是使用 LINQ 映射模式裝飾器創建類 - 從而選擇我想要合並到表的哪些部分的類。

一個簡單的例子：

private DateTime? _LocalCopyTimestamp = (DateTime)SqlDateTime.MinValue;
[Column(Name = "recaLocalCopyTimestamp", Storage = "_LocalCopyTimestamp", CanBeNull = true)]
public DateTime? LocalCopyTimestamp
{
    get
    {
        return this._LocalCopyTimestamp;
    }
    set
    {
        this._LocalCopyTimestamp = value;
    }
}

由於項目限制（處理模式更改的方式以及因為存在現有數據庫模式並且它有點過於有機和不嚴格），我沒有使用並且不願意求助於建模工具

有沒有辦法讓實體框架具有這種靈活性，而不必包含架構信息文件和/或許多不同的代碼文件？

然后我是否還可以創建“使用”多個基礎表的類？

誰能指出我有關此的文檔？

Answer 1

您請求的功能（編寫 C# 類並從中生成 model）被實體框架團隊稱為“ Model First ”。 它在實體框架的當前發布版本中不存在，但它是下一個版本的計划功能。 如果您觀看PDC 的 Entity Framework 演講，您可以看到此新功能的演示。 在當前版本中，您不必編寫“許多”映射文件，但您確實需要一個（EDMX 文件），它必須是 XML。

是的，您可以創建使用多個基礎表的實體類。 這稱為“ 實體拆分”。 鏈接中的分步說明。 一般來說，你會發現Entity Framework支持比LINQ到SQL更復雜的映射場景。

恐怕我不得不完全不同意 Marc 關於在不使用設計器的情況下編寫 EDMX 的觀點。 不使用設計器編寫 EDMX 不僅是可能的，而且對於超出某一方面的項目，這幾乎是不可避免的。 對此有幾點看法：

1. 對於實體框架的大部分早期歷史（RTM 之前；“ ObjectSpaces ”），手動編寫 XML 文件是使用該工具的唯一方法。 設計器是一個最近的特性，並且遠不如實體框架本身穩定。
2. 設計器根本不支持某些實體框架功能，例如復雜類型。
3. 設計器不支持某些映射方案，例如不映射單個列，或映射沒有外鍵關系的表，這可能是遺留數據庫所必需的。
4. 正如我在 (1) 中提到的，設計器比實體框架本身要復雜得多。 因此，在較大的項目中，您可能最終不得不在設計師的錯誤之后進行清理。

Answer 2

Entity Framework 使用 EDM 轉 model 數據； 這是一組 3 個復雜的模式文件（存儲、概念、映射），最常作為資源存儲在項目中（通過使用單個 EDMX 文件生成所有 3 個模式文件的設計器）。

它不支持此信息的屬性類。 編寫 EDM 的唯一明智方法是通過設計器（本質上是您不喜歡的建模工具）。

重新對“使用”多個基礎表進行分類； 是的，概念層的單個實體框架實體（即類）可以跨越多個存儲表。 這對於一些 inheritance 示例特別有用，但也可以 (IIRC) 用於平面模型。 您可以通過存儲層和概念層之間的“映射”（最常見；在設計器的選項卡上）來執行此操作。