Как сначала удалить подчеркивание полей внешнего ключа в коде по соглашению

Наконец-то я нашел ответ на этот вопрос, написав собственное соглашение. Это соглашение работает в EF 6.0 RC1 (код с прошлой недели), поэтому я думаю, что оно продолжит работать после выпуска EF 6.0.

При таком подходе стандартные соглашения EF определяют независимые ассоциации (IA), а затем создают EdmProperty для поля внешнего ключа. Затем появляется это соглашение и переименовывает поля внешнего ключа.

/// <summary>
/// Provides a convention for fixing the independent association (IA) foreign key column names.
/// </summary>
public class ForeignKeyNamingConvention : IStoreModelConvention<AssociationType>
{

    public void Apply(AssociationType association, DbModel model)
    {
        // Identify a ForeignKey properties (including IAs)
        if (association.IsForeignKey)
        {
            // rename FK columns
            var constraint = association.Constraint;
            if (DoPropertiesHaveDefaultNames(constraint.FromProperties, constraint.ToRole.Name, constraint.ToProperties))
            {
                NormalizeForeignKeyProperties(constraint.FromProperties);
            }
            if (DoPropertiesHaveDefaultNames(constraint.ToProperties, constraint.FromRole.Name, constraint.FromProperties))
            {
                NormalizeForeignKeyProperties(constraint.ToProperties);
            }
        }
    }

    private bool DoPropertiesHaveDefaultNames(ReadOnlyMetadataCollection<EdmProperty> properties, string roleName, ReadOnlyMetadataCollection<EdmProperty> otherEndProperties)
    {
        if (properties.Count != otherEndProperties.Count)
        {
            return false;
        }

        for (int i = 0; i < properties.Count; ++i)
        {
            if (!properties[i].Name.EndsWith("_" + otherEndProperties[i].Name))
            {
                return false;
            }
        }
        return true;
    }

    private void NormalizeForeignKeyProperties(ReadOnlyMetadataCollection<EdmProperty> properties)
    {
        for (int i = 0; i < properties.Count; ++i)
        {
            string defaultPropertyName = properties[i].Name;
            int ichUnderscore = defaultPropertyName.IndexOf('_');
            if (ichUnderscore <= 0)
            {
                continue;
            }
            string navigationPropertyName = defaultPropertyName.Substring(0, ichUnderscore);
            string targetKey = defaultPropertyName.Substring(ichUnderscore + 1);

            string newPropertyName;
            if (targetKey.StartsWith(navigationPropertyName))
            {
                newPropertyName = targetKey;
            }
            else
            {
                newPropertyName = navigationPropertyName + targetKey;
            }
            properties[i].Name = newPropertyName;
        }
    }

}

Обратите внимание, что соглашение добавляется к вашему DbContext в вашем переопределении DbContext.OnModelCreating, используя:

modelBuilder.Conventions.Add(new ForeignKeyNamingConvention());

Вы можете сделать одно из двух:

1. Следуйте соглашениям EF при именовании внешних ключей, т. е. если у вас есть виртуальный Address, определите свойство ключа как AddressId.

2. Явно укажите EF, что использовать. Один из способов сделать это — использовать Fluent API, как вы сейчас делаете. Однако вы также можете использовать аннотации данных:

   [ForeignKey("Address")]
   public int? AddressGlobalKey { get; set; }
   
   public virtual Address Address { get; set; }
   

Это ваш единственный выбор.

Я знаю, что это немного устарело, но вот пример того, как я указываю сопоставление столбцов с помощью моей гибкой конфигурации (OnModelCreating):

modelBuilder.Entity<Application>()
            .HasOptional(c => c.Account)
                .WithMany()
                .Map(c => c.MapKey("AccountId"));

Надеюсь это поможет,

Я также видел ту же проблему, когда тип поля выключен. Дважды проверьте тип поля Пример:

public string StateId {get;set;}

указывающий на объект домена с int в качестве типа State.Id. Убедитесь, что ваши типы совпадают.

Я обнаружил, что настройки ключевых столбцов не перехватываются конвенцией ForeignKeyNamingConvention. Внес это изменение, чтобы поймать их.

private bool DoPropertiesHaveDefaultNames(ReadOnlyMetadataCollection<EdmProperty> properties, string roleName, ReadOnlyMetadataCollection<EdmProperty> otherEndProperties)
{
    if (properties.Count == otherEndProperties.Count)
    {
        for (int i = 0; i < properties.Count; ++i)
        {
            if (properties[i].Name.EndsWith("_" + otherEndProperties[i].Name))
            {
                return true;
            }
            else
            {
                var preferredNameProperty =
                    otherEndProperties[i]
                        .MetadataProperties
                        .SingleOrDefault(x => x.Name.Equals("PreferredName"));

                if (null != preferredNameProperty)
                {
                    if (properties[i].Name.EndsWith("_" + preferredNameProperty.Value))
                    {
                        return true;
                    }
                }
            }
        }
    }
    return false;
}

У меня были проблемы при объединении его с соглашением об именах идентификаторов EntityNameId.

При использовании следующего соглашения для обеспечения того, чтобы таблица Customer имела CustomerId, а не просто Id.

modelBuilder.Properties()
                        .Where(p => p.Name == "Id")
                        .Configure(p => p.IsKey().HasColumnName(p.ClrPropertyInfo.ReflectedType == null ? "Id" : p.ClrPropertyInfo.ReflectedType.Name +"Id"));

Соглашение об именовании внешнего ключа необходимо изменить на следующее.

 /// <summary>
    /// Provides a convention for fixing the independent association (IA) foreign key column names.
    /// </summary>
    public class ForeignKeyNamingConvention : IStoreModelConvention<AssociationType>
    { 
        public void Apply(AssociationType association, DbModel model) 
        { 
            // Identify ForeignKey properties (including IAs)  
            if (!association.IsForeignKey) return;

            // rename FK columns  
            var constraint = association.Constraint; 
            if (DoPropertiesHaveDefaultNames(constraint.FromProperties, constraint.ToProperties)) 
            { 
                NormalizeForeignKeyProperties(constraint.FromProperties); 
            } 

            if (DoPropertiesHaveDefaultNames(constraint.ToProperties, constraint.FromProperties)) 
            { 
                NormalizeForeignKeyProperties(constraint.ToProperties); 
            }
        } 

        private static bool DoPropertiesHaveDefaultNames(IReadOnlyList<EdmProperty> properties, IReadOnlyList<EdmProperty> otherEndProperties) 
        { 
            if (properties.Count != otherEndProperties.Count) 
            { 
                return false; 
            } 

            for (var i = 0; i < properties.Count; ++i)
            {
                if (properties[i].Name.Replace("_", "") != otherEndProperties[i].Name) 
                { 
                    return false; 
                } 
            } 

            return true; 
        } 

        private void NormalizeForeignKeyProperties(ReadOnlyMetadataCollection<EdmProperty> properties) 
        { 
            for (var i = 0; i < properties.Count; ++i) 
            { 
                var underscoreIndex = properties[i].Name.IndexOf('_'); 
                if (underscoreIndex > 0) 
                { 
                    properties[i].Name = properties[i].Name.Remove(underscoreIndex, 1); 
                }                 
            } 
        } 
    }

Большинство этих ответов связаны с независимыми ассоциациями (где определено свойство навигации «MyOtherTable», но не «int MyOtherTableId») вместо ассоциаций внешнего ключа (где определены оба).

Это нормально, поскольку вопрос касается IA (он использует MapKey), но я столкнулся с этим вопросом при поиске решения той же проблемы с FKA. Поскольку другие люди могут прийти сюда по той же причине, я решил поделиться своим решением, в котором используется ForeignKeyDiscoveryConvention.

https://stackoverflow.com/a/43809004/799936