Entity framework 4 是否有方法撤消/删除/回滚EF 4.3外键命名约定？

首先使用EF代码，我们有一个db种子设定框架，它使用依赖注入的db初始值设定项和种子设定项用样本测试数据填充一个开发数据库

其中一些种子操作需要导入大量数据，因此对于一些表，我们使用实际的SQL文件和INSERT语句。对于某些insert语句，必须禁用外键，然后重新启用：

ALTER TABLE [Schema].[TableName] NOCHECK CONSTRAINT [TableName_FkPropertyName]
-- perform a block of inserts
ALTER TABLE [Schema].[TableName] CHECK CONSTRAINT [TableName_FkPropertyName]

我刚刚从EF 4.2更新到EF 4.3，并注意到这些已经不起作用了。对EF创建的db的检查表明，FK现在的名称不同：

FK_CodeFolder1.Table1Name_CodeFolder2.Table2Name_DbFkColumnName

有没有办法取消这个命名约定，回到原来的命名约定？如果不是的话，这怎么不是一个问题

在Ladislav回复后更新

---

拉迪斯拉夫是对的，我上面对新命名模式的解释不太正确。我已经更新了。前面的部分。不是完整命名空间，但它是实体模型项目中的文件夹名称。因此，如果我在文件夹AggregateSet1中有一个实体WidgetAbc，那么fk模式片段将是

AggregateSet1.WidgetAbc

，而不仅仅是

WidgetAbc

，为什么您认为这是一个问题或破坏性的更改？IMHO这是EF内部行为-您首先使用代码，在这种方法中，您不应该直接使用数据库，尤其不应该将自定义数据库脚本基于硬编码名称，因为您无法控制它们的生成

我不认为您可以恢复该行为，但您可以开始使用迁移并对表定义进行编码-方法应该允许您命名FK约束

顺便说一句，我在EFv4.3中看到FK约束的不同命名模式：

FK_DependentTableName_PrincipalTableName_FKColumnName

---

我不同意控制名字的产生。API让您可以控制命名SQL中可以具体化的所有其他内容——模式名、表名、列名等。如果新的命名约定至少已经发布，那将非常有用。我们很幸运，因为在大多数情况下，我们完全按照您所说的去做——没有创建很多自定义SQL，如视图、索引、存储过程等。我期待着在新的迁移功能成熟后使用它们，但仍想了解为什么必须更改此命名模式。如果您想知道更改此模式的原因，请直接询问ADO.NET团队。FK命名是否有任何更改的官方信息？在4.3或更高版本中创建的迁移从db模式中删除FK，而在4.3之前的版本中创建FK，当您应用迁移时，这是一个突破性的更改！