实体框架4.1：名称约束

我们正在使用实体框架4.1 - 代码优先。我们需要能够命名我们的约束，而不是由SQL Server自动生成其名称。这可能吗？实体框架4.1：名称约束

我们需要：PK_Users_UserId，不：PK_Users_87329729C

2011-12-12 mtm927

你可以在创建后运行一些原始的sql来重命名它们吗？您可能需要禁用EdmMetadata约定。

context.Database.ExecuteSqlCommand(
    @"DECLARE @pk sysname 
    SELECT @pk = name FROM sysobjects WHERE parent_obj = object_id('users') and xtype = 'pk' 
    EXEC sp_rename @pk, 'pk_users_UserId' 
");

来源

2011-12-13 08:16:49 Betty

我做了类似的事情。当EF创建数据库时，我们在Seed（）中实现了一些代码，循环遍历主键约束并将它们重命名为PK_ [表名]。这个解决方案已经为我们工作，但我希望看到能够通过流利的API明确命名约束。附：我们只留下了EdxMetadata表，我用它来确定模型是否已经改变（从而强制删除/重新创建数据库）。 – mtm927

简短的回答是否定的。较长的答案是关于代码的含义。代码优先意味着你对数据库不感兴趣 - 你只需让EF创建一些，这就是你所需要的。它允许您为表和列定义名称（这对于使用现有数据库尤其有用），但仅此而已。

如果您需要在这样的级别使用数据库，则需要使用数据库优先的方法。首先滥用代码来命名约束是可能的，但它非常困难和复杂（它需要在创建后删除旧约束并创建一个新约束 - 例如here）。

来源

2011-12-12 16:54:16

谢谢，那就是我所害怕的。我们遇到的问题是将开发数据库与登台数据库进行比较，并尝试编写变更的脚本。约束虽然具有相同的目的，但命名不同，因此，比较脚本是无用的。关于如何在不删除/重新创建暂存数据库的情况下将更改从开发移动到暂存的任何想法？ – mtm927

我不同意“*你对数据库不感兴趣”的说法。 ORM是一个抽象概念，它们可以帮助你更高层次地思考，但在一天结束时，DB很重要。与EF不同，NH例如允许您使用任何您想要的约定来命名您的密钥。 –

@DiegoMijelshon我不同意你的看法，所以这似乎是一个品味问题。在DDD方法中，数据库并不重要。您的POCO和您的业务逻辑是其核心。 DAL应该通过通用接口和可切换的方式暴露出来，所以相同的BLL和上层（UI）不知道底层是什么：可能是sql server，mysql，xml文件，excel spreasheet，模拟框架等等。只要DAL尊重合同，一切都很好。所以在这种方法中，数据库并不重要，它只是一个工具，一个重要的实现，即抽象。 –

实体框架4.1：名称约束

回答

相关问题