Исправить несовместимое с Entity Framework подчеркивание FK

Меня устраивает FK-имена "Table_Id" ИЛИ "TableId" в моей таблице. Но генератор SQL Entity Framework использует и то, и другое.

  • Сопоставленные ассоциации (независимые ассоциации, видимые свойства FK): без подчеркивания
  • Ограниченные ассоциации (ассоциации внешних ключей): подчеркивание

Это кажется смешным - с точки зрения БД нет никакой разницы между этими двумя отношениями, поэтому согласованность здесь кажется очевидной. Я строю Model First.

Я что-то делаю не так или есть способ это исправить?


РЕДАКТИРОВАТЬ: По запросу, включая образец. Я создал новую диаграмму Entity и сгенерировал SQL. Это подтверждает. Вот снимок диаграммы и сценария создания базы данных из модели. Обратите внимание на BasketId для яблок и Basket_Id для апельсинов. Единственная разница заключается в выборе «Добавить свойства внешнего ключа к объекту «Апельсины»». при добавлении этой ассоциации.

введите здесь описание изображения

-- --------------------------------------------------
-- 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
-- ------------------------


person shannon    schedule 30.04.2013    source источник
comment
Я думаю, что у вас неправильное сопоставление, ваш столбец TableId не сопоставлен должным образом. Вот почему EF использует значение по умолчанию. Можете ли вы опубликовать свои два класса сущностей и сопоставления (если есть)?   -  person Jayantha Lal Sirisena    schedule 30.04.2013
comment
Выполнено. дайте мне знать, если это то, что вы имели в виду.   -  person shannon    schedule 30.04.2013
comment
Здесь нет ничего плохого. Вы можете сделать то же самое и для оранжевого, чтобы иметь BasketId и в оранжевом.   -  person Jayantha Lal Sirisena    schedule 30.04.2013
comment
Воспроизводимость не означает, что это правильно. Да, я мог бы изменить свои модели и выставить FK на всех из них, чтобы скрыть то, что кажется несоответствием. Не понимаю, почему такое несоответствие.   -  person shannon    schedule 30.04.2013


Ответы (1)


Вы правы, с точки зрения модели данных разницы нет, но есть разница с точки зрения объектной модели.

Когда вы используете свойства внешнего ключа, идентификатор внешнего ключа включается в сущность, но если вы этого не делаете, внешний ключ используется молча. Именование является частью политики Entity Framework «Соглашение важнее конфигурации». EF видит свойство с именем Basket_Id и не видит свойство в сущности, поэтому он знает, что этот идентификатор можно использовать без его специальной настройки.

Напротив, когда Ef видит BasketId и видит свойство в сущности, он знает, что это поле необходимо сопоставить с базовым столбцом BasketId.

По сути, EF различает два типа навигации по внешнему ключу, используя соглашение об именах. Подробнее об этом можно прочитать здесь:

Правила создания свойств навигации Entity Framework

Если вы хотите изменить это поведение, вы можете создать собственное соглашение об именах, удалить соглашение по умолчанию и добавить свое собственное, которое называет вещи так, как вы хотите, однако это вполне может вызвать конфликты с другим типом навигации.

Честно говоря, я нахожу немного ироничным то, что вы хотите жаловаться на согласованность, когда вы непоследовательны в том, как вы определяете свои навигационные свойства. Придерживайтесь одного или другого, если последовательность так важна для вас.

person Erik Funkenbusch    schedule 30.04.2013
comment
Нет никакой иронии. Мне пришлось материализовать сводную/отображающую таблицу, чтобы компенсировать недостаток EF, и показать FK, чтобы пометить их как составной первичный ключ. Но спасибо за ответ, ссылка особенно объяснила суть. Примечание: обнаружение FK на некоторых элементах было бы несоответствием в OM, а не в DM. - person shannon; 30.04.2013
comment
КСТАТИ. Проблема с несоответствием заключается в том, что я опасаюсь, что DM сломается, если я обнаружу, что мне нужно раскрыть дополнительные FK в будущем. Да, я забочусь о последовательности, но меня больше волнует, что/почему/как вещи происходят под обложкой, поэтому я понимаю, чего ожидать. Ваш заключительный комментарий был более враждебным, чем это было необходимо. В конце концов, я спросил, не делаю ли я что-то не так. - person shannon; 30.04.2013
comment
@Shannon - я не был противником, я был сбит с толку, почему вы беспокоитесь о последовательности, когда вы сами не были последовательны. Вы всегда можете использовать атрибуты данных или свободное сопоставление, чтобы настроить его так, чтобы он делал все, что вы хотите, поэтому нет опасности, что что-то сломается. Я бы также сказал, что если вы так обеспокоены моделью данных, вам следует создать базу данных так, как вы хотите, и вместо этого использовать Database First. - person Erik Funkenbusch; 30.04.2013
comment
Спасибо разъяснение. В моем последнем проекте я сначала использовал базу данных, что, вероятно, объясняет, откуда взялась моя критичность к выходным данным DM. Но я надеялся вложить меньше усилий в миграцию развертывания/обновления для этого проекта. В любом случае, это, вероятно, несбыточная мечта, потому что, насколько я знаю, Model-First Migrations все еще недоступны. - person shannon; 30.04.2013