c# - 我可以像使用 LINQ to SQL 一样使用 Entity Framework 吗？

Question

我已经开始尝试使用 LINQ to 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;
    }
}

由于项目限制(模式更改的处理方式以及现有的数据库模式，它有点过于有机和不严格)，我没有使用也不愿意求助于建模工具

有没有一种方法可以让 Entity Framework 具有这种灵 active ，而不必包含架构信息文件和/或大量不同的代码文件？

然后我是否也可以创建“使用”多个基础表的类？

谁能指点我相关的文档？

Answer 1

您请求的功能(编写 C# 类并从中生成您的模型)由 Entity Framework 团队命名为“Model First”。它不存在于 Entity Framework 的当前发布版本中，而是下一个版本的计划功能。如果你看Entity Framework talks from PDC ，您可以看到此新功能的演示。使用当前版本，您不必编写“许多”映射文件，但您确实需要一个(EDMX 文件)，而且它必须是 XML。

是的，您可以创建使用多个基础表的实体类。这称为“Entity splitting”。链接中的分步说明。一般来说，您会发现 Entity Framework 支持比 LINQ to SQL 更复杂的映射场景。

恐怕我不得不完全不同意 Marc 关于在不使用设计器的情况下编写 EDMX 的观点。不使用设计器编写 EDMX 不仅是可能的，而且对于超过某一方面的项目，这几乎是不可避免的。关于这一点的几点:

1. 对于 Entity Framework 的大部分早期历史(RTM 之前；“ObjectSpaces”)，手动编写 XML 文件是使用该工具的唯一方式。设计器是一项最新功能，远不如 Entity Framework 本身稳定。
2. 设计器根本不支持某些 Entity Framework 功能，例如复杂类型。
3. 设计器不支持某些映射场景，例如不映射单个列或映射没有外键关系的表，这对于遗留数据库可能是必需的。
4. 正如我在 (1) 中提到的，设计器比 Entity Framework 本身更容易出错。因此，在较大的项目中，您可能最终不得不在设计师犯错后进行清理。