C# 实体框架4.1 DbContext生成器问题

我是实体框架4.1的新手，我真的很想为我的模型转换到POCO类。我发现，使用安装EF4.1时提供的“DbContext生成器”项，这非常容易。它完全按照我的要求做了，并为我现有的EDMX模型生成了DbContext对象和所有POCO

我运行了这个应用程序，并测试它是否仍在工作。是的。很高兴我删除了EDMX文件和T4模板，并开始重新组织我的新POCO。然而，在再次正确构建之后，我遇到了一个运行时问题。实例化DbContext时，无法找到元数据文件：.csdl、.ssdl、&.msl（我真的不知道它们是什么，只是它们是所有EF连接字符串的一部分）

放回我的EDMX后，它又正常运行了。我真的不想要EDMX文件了。我真的很想坚持POCO类，忘记EDMX曾经存在过；特别是因为我不希望它运行那些T4模板并重新生成我的POCO

我有四个相关问题：

为什么我必须在我的项目中保留edmx

有解决办法吗

当您使用EF4.1执行真正的“代码优先”时会发生什么，这些元数据文件是从哪里获得的

这些元数据文件到底是什么

---

这样不行。如果您决定使用DbContext生成器，则表示将在EDMX文件中描述您的映射。在编译过程中，EDMX文件被分解为三个独立的文件，扩展名分别为.ssdl、.csdl和.msl。这些元数据文件描述您的数据库、实体以及从数据库到实体的映射。默认情况下，这些文件作为资源存储在编译的程序集中，并从传递给

DbContext

实例的连接字符串中引用。如果要使用生成器创建的

DbContext

，则必须将EDMX文件保留在项目中。它与EFv1中使用的映射方法相同，EFv4=它不是代码优先

代码优先意味着没有EDMX和T4模板为您生成映射和代码。在正常情况下，代码首先意味着在拥有任何数据库之前编写类，并且数据库由EF创建。许多人在现有数据库中使用这种方法，并手动将他们的类映射到现有数据库，但这需要一些EF方面的知识/经验（或者您可以在这里提出有针对性的问题，我们将帮助您）

上下文需要元数据来执行映射和SQL命令生成。EDMX映射策略使用上述XML文件中定义的元数据。代码优先映射策略使用一些默认约定、fluent API或数据注释从编译后的代码中获取元数据

有一个单独的项目允许从现有数据库生成代码优先映射-我在您的示例中指出了该项目

EDMX文件负责在编译时将CSDL、SSDL和MSL元数据资源嵌入程序集中

对。您将需要实体框架电动工具CTP1。有关链接，请参见Mystere Man对该问题的回答。这将是从现有数据库到代码优先的真正转换。这意味着您的代码将推动模式向前发展，而不是相反

在进行真正的代码优先开发时，CSDL、SSDL和MSL元数据资源仍然存在。它们只是在构建时从对象模型推断出来的。因为代码控制模型和模式，所以它能够自己推断这些资源。但在某些情况下，它不知道从代码中推断出什么。例如，如果更改实体属性名称，则无法知道是要删除旧列（属性名称）并使用新名称添加新列，还是要保留旧列并使用新名称重命名。这就是为什么EF代码没有很好的数据/模式迁移，以及为什么每次在代码中更改模型时它都会删除并重新创建整个数据库

DbContext API的这一缺点无疑是最大的问题，如上所述，ADO.NET团队目前正在解决这一问题

目前，我个人选择手动修改数据库，然后简单地更新我的C#代码以反映它。这需要一些关于这些东西如何工作的知识，我还在练习。另一种方法是将EDMX文件留在那里，像平常一样进行更新，并在情况发生变化时让它重新生成POCO。但是，这与执行经典EF更新几乎没有什么不同，因为POCO的任何更改在重新生成时都将被覆盖

另一种解决方案是再次保留EDMX文件，并在情况发生变化时进行更新，但将“保存时转换相关文本模板”属性设置为false

这将防止EDMX运行T4模板并重新生成POCO。因此，您只需对其进行更新，以确保元数据资源保持准确。但是，您需要手动修改POCO以反映对模型/模式的任何更改。这仍然需要做更多的工作，而不仅仅是让它生成代码，但以我的拙见，这有利于学习

CSDL、SSDL和MSL是EF的元数据资源。它们帮助EF确定如何将结果集映射到对象模型，反之亦然。它是数据库模式和代码之间的桥梁。无论您以何种方式使用EF，这些资源都存在，只是它们的生成方式有所不同

你应该。它描述了不同的项目类型

---

简单的回答是，在使用dbcontext生成器时需要.edmx文件。如果您想先使用代码，您必须手动描述模型，或者使用实体框架power tools CTP1对代码优先模型进行反向工程。

power tools非常棒！这是一个真正的反向发动机