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

Question

我已经开始尝试使用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中具有这种灵活性,而不必包含架构信息文件和/或许多不同的代码文件？

那么我是否还可以创建"使用"多个基础表的类？

谁能指点我这方面的文件？

Answer 1

您要求的功能(编写C#类并从中生成模型)由实体框架团队称为" 模型优先".它不存在于实体框架的当前发布版本中,但是是下一版本的计划功能.如果您观看来自PDC的实体框架会话,您可以看到此新功能的演示.使用当前版本,您不必编写"许多"映射文件,但您确实需要一个(EDMX文件),它必须是XML.

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

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

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