修复实体框架不一致的FK下划线

Question

我的表中的“Table_Id” OR “TableId”的FK名称很好。但实体框架SQL生成器正在使用它们。

• 映射关联（独立关联，FK属性可见）：无下划线
• 约束关联（外键关联）：下划线

这种看起来很荒谬 - 从数据库的角度来看，这两种关系没有区别，因此这里的一致性似乎是显而易见的。我正在建立Model First。

我做错了什么或者有办法解决这个问题吗？

---

编辑： 根据要求，包括样品。我创建了一个新的实体图并生成了SQL。它验证。这是图表的快照和从模型脚本生成数据库。注意Apple上的BasketId和Oranges上的Basket_Id。唯一的区别是选择了“向'Oranges'实体添加外键属性。”添加该关联时。

-- --------------------------------------------------
-- Entity Designer DDL Script for SQL Server 2005, 2008, and Azure
-- --------------------------------------------------
-- Date Created: 04/29/2013 23:38:07
-- Generated from EDMX file: C:\data\web-trunk\TestEntities.Data\TestEntities.edmx
-- --------------------------------------------------

SET QUOTED_IDENTIFIER OFF;
GO
USE [TestEntities];
GO
IF SCHEMA_ID(N'dbo') IS NULL EXECUTE(N'CREATE SCHEMA [dbo]');
GO

-- --------------------------------------------------
-- Dropping existing FOREIGN KEY constraints
-- --------------------------------------------------


-- --------------------------------------------------
-- Dropping existing tables
-- --------------------------------------------------


-- --------------------------------------------------
-- Creating all tables
-- --------------------------------------------------

-- Creating table 'Baskets'
CREATE TABLE [dbo].[Baskets] (
    [Id] int IDENTITY(1,1) NOT NULL
);
GO

-- Creating table 'Apples'
CREATE TABLE [dbo].[Apples] (
    [Id] int IDENTITY(1,1) NOT NULL,
    [BasketId] int  NOT NULL
);
GO

-- Creating table 'Oranges'
CREATE TABLE [dbo].[Oranges] (
    [Id] int IDENTITY(1,1) NOT NULL,
    [Basket_Id] int  NOT NULL
);
GO

-- --------------------------------------------------
-- Creating all PRIMARY KEY constraints
-- --------------------------------------------------

-- Creating primary key on [Id] in table 'Baskets'
ALTER TABLE [dbo].[Baskets]
ADD CONSTRAINT [PK_Baskets]
    PRIMARY KEY CLUSTERED ([Id] ASC);
GO

-- Creating primary key on [Id] in table 'Apples'
ALTER TABLE [dbo].[Apples]
ADD CONSTRAINT [PK_Apples]
    PRIMARY KEY CLUSTERED ([Id] ASC);
GO

-- Creating primary key on [Id] in table 'Oranges'
ALTER TABLE [dbo].[Oranges]
ADD CONSTRAINT [PK_Oranges]
    PRIMARY KEY CLUSTERED ([Id] ASC);
GO

-- --------------------------------------------------
-- Creating all FOREIGN KEY constraints
-- --------------------------------------------------

-- Creating foreign key on [Basket_Id] in table 'Oranges'
ALTER TABLE [dbo].[Oranges]
ADD CONSTRAINT [FK_BasketOrange]
    FOREIGN KEY ([Basket_Id])
    REFERENCES [dbo].[Baskets]
        ([Id])
    ON DELETE NO ACTION ON UPDATE NO ACTION;

-- Creating non-clustered index for FOREIGN KEY 'FK_BasketOrange'
CREATE INDEX [IX_FK_BasketOrange]
ON [dbo].[Oranges]
    ([Basket_Id]);
GO

-- Creating foreign key on [BasketId] in table 'Apples'
ALTER TABLE [dbo].[Apples]
ADD CONSTRAINT [FK_BasketApple]
    FOREIGN KEY ([BasketId])
    REFERENCES [dbo].[Baskets]
        ([Id])
    ON DELETE NO ACTION ON UPDATE NO ACTION;

-- Creating non-clustered index for FOREIGN KEY 'FK_BasketApple'
CREATE INDEX [IX_FK_BasketApple]
ON [dbo].[Apples]
    ([BasketId]);
GO

-- --------------------------------------------------
-- Script has ended
-- ------------------------

---

Answer 1

你是对的，与数据模型的观点没有区别，但与对象模型的观点存在差异。

当您使用外键属性时，外键ID包含在实体中，但是当您不使用外键时，则会以静默方式使用外键。命名是实体框架“约定优于配置”策略的一部分。 EF看到名为Basket_Id的属性，并且没有在实体中看到该属性，因此它知道在没有专门配置的情况下使用此ID。

相比之下，当Ef看到BasketId并看到实体中的属性时，它就知道将该字段映射到底层的BasketId列。

基本上，EF通过使用命名约定来区分两种类型的外键导航。你可以在这里阅读更多相关信息：

Entity Framework Navigation Property generation rules

如果要更改此行为，可以创建自定义命名约定，删除默认命名约定，然后添加以您希望的方式命名的自定义命名约定，但这很可能会导致与其他类型的导航冲突

老实说，当你在如何定义导航属性方面存在不一致时，我觉得有点讽刺的是你想抱怨一致性。如果一致性对你很重要，请坚持使用其中一种。