實體框架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：名稱約束

回答

相關問題