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

时间:2009-03-10 05:16:36

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

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

由于项目限制(处理架构更改的方式以及因为存在现有的数据库架构并且有点过于有机和非严格),我没有使用并且不愿意使用建模工具。

是否有办法在不必包含架构信息文件和/或许多不同代码文件的情况下为Entity Framework提供这种灵活性?

我是否可以创建“使用”多个基础表的类?

有人能指出我有关此事的文件吗?

2 个答案:

答案 0 :(得分:8)

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

是的,您可以创建使用多个基础表的实体类。这称为“Entity splitting”。链接上的分步说明。通常,您会发现实体框架支持比LINQ to SQL更复杂的映射方案。

我担心我必须完全不同意Marc关于在不使用设计师的情况下编写EDMX的问题。不使用设计师编写EDMX不仅是可能的,而且对于超出某一方面的项目,它几乎是不可避免的。关于这一点的几点:

  1. 对于实体框架的大部分早期历史(RTM之前;“ObjectSpaces”),手动编写XML文件是使用该工具的唯一方法。设计器是最近的一个特性,并且比实体框架本身稳定得多。
  2. 某些实体框架功能,例如复杂类型,设计师根本不支持。
  3. 设计人员不支持某些映射方案,例如不映射单个列,或者没有外键关系的映射表,这可能是旧数据库所必需的。
  4. 正如我在(1)中提到的那样,设计师比实体框架本身有点笨拙。所以在较大的项目中,你可能最终不得不在设计师的错误之后进行清理。

答案 1 :(得分:1)

实体框架使用EDM对数据建模;这是一组3个复杂的模式文件(存储,概念,映射),最常见的存储为项目中的资源(通过设计器使用单个EDMX文件生成所有3个模式文件)。

它不支持此信息的属性类。编写EDM的唯一合理方法是通过设计器(实际上是您不喜欢的建模工具)。

重新对“使用”多个基础表进行分类;是的,概念层(即类)的单个实体框架实体可以跨越多个存储表。这对于某些继承示例特别有用,但也可以由平面模型使用(IIRC)。您可以通过存储层和概念层之间的“映射”(最常见的是,在设计器的选项卡上)执行此操作。