我可以像使用 LINQ to SQL 一样使用实体框架吗？答案

【问题标题】：Can I use the Entity Framework like I use LINQ to SQL?我可以像使用 LINQ to SQL 一样使用实体框架吗？
【发布时间】：2009-03-10 05:16:36
【问题描述】：

我已经开始尝试使用 LINQ to SQL，我所做的基本上是使用 LINQ 映射装饰器创建类 - 从而选择我想将 db 表架构的哪些部分合并到我的类中。

一个简单的例子：

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

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

有没有办法让实体框架具有这种灵活性，而不必包含架构信息文件和/或大量不同的代码文件？

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

谁能指点我有关这方面的文档？

【问题讨论】：

标签： c# linq-to-sql entity-framework linq-to-entities

【解决方案1】：

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

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

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

对于实体框架的大部分早期历史（RTM 之前；“ObjectSpaces”），手动编写 XML 文件是使用该工具的唯一方法。设计器是一个新功能，与实体框架本身相比稳定性要差得多。
设计器根本不支持某些实体框架功能，例如复杂类型。
设计器不支持某些映射方案，例如不映射单个列或映射没有外键关系的表，这对于旧数据库可能是必需的。
正如我在 (1) 中所提到的，设计器比实体框架本身更容易出错。因此，在大型项目中，您可能最终不得不在设计师犯错后进行清理。

【讨论】：

不错的回答，我觉得按照你说的，最好等下个版本。
你对设计师的点都记下了。我也同意 leppie 的观点：我正在等待下一个版本；-p 在 MVP 峰会上花了一天时间查看它 - 看起来比现在的版本好多了。
“对于实体框架的大部分历史”......好吧，对于 RTM 历史，它们都有相同的年龄......

【解决方案2】：

Entity Framework 使用 EDM 对数据进行建模；这是一组 3 个复杂的模式文件（存储、概念、映射），最常作为资源存储在项目中（通过使用单个 EDMX 文件生成所有 3 个模式文件的设计器）。

它不支持此信息的属性类。编写 EDM 的唯一明智方法是通过设计器（本质上是您不喜欢的建模工具）。

重新分类“使用”多个基础表；是的，概念层的单个实体框架实体（即类）可以跨越多个存储表。这对于某些继承示例特别有用，但也可以（IIRC）被平面模型使用。您可以通过存储层和概念层之间的“映射”（最常见；在设计器的选项卡上）来实现。

【讨论】：