外键导航属性命名约定的替代品 [英] Foreign key navigation property naming convention alternatives

问题描述

在使用实体框架4.1，是否有替代的命名约定导航属性。

When using Entity Framework 4.1, are there alternatives to the naming conventions for Navigation Properties?

例如，而不是这样做的：

For example instead of doing this:

public virtual MyObject MyObject { get; set; }

为

To be

public virtual MyObject SomeOtherName { get; set; }

更新：

在该 [ForeignKey的（OldStepId）] 和 [ForeignKey的（NewStepId）] 属性被添加，生成的SQL就变成了：

When the [ForeignKey("OldStepId")] and [ForeignKey("NewStepId")] attribute is added, the generated SQL then becomes:

{SELECT 
`Extent1`.`CompletedId`, 
`Extent1`.`OldStepId`, 
`Extent1`.`NewStepId`, 
`Extent1`.`Name`, 
`Extent1`.`Step_StepId`, 
`Extent1`.`Step_StepId1` 
FROM `Completed` AS `Extent1`}

其中，不存在的最后两列。

which, the last two columns do not exist.

推荐答案

您可以使用数据注释或流畅API来做到这一点。

You can use the Data Annotations or the Fluent API to do this

属性的方式

public virtual Int32 MyObjectId{get;set;}
[ForeignKey("MyObjectId")]
public virtual MyObject SomeOtherName { get; set; }

流利路

Fluent Way

modelBuilder.Entity<Type>()
    .HasRequired(p => p.SomeOtherName)
    .WithMany(d => d.Type)
    .HasForeignKey(p => p.MyObjectId)

响应更新

如果您在MyOjbect类有一个列表，那么你就需要来标记列表作为 [InverseProperty（SomeOtherName）] 。这也许就是为什么你在你的SQL获得额外列。这使得从告诉发电机所在的主柱真的是被成倍上涨的双向关系。

If you have a List in your MyOjbect class, then you need to mark that List as [InverseProperty("SomeOtherName")]. This might be why you are getting extra columns in your SQL. This keeps two-way relationships from being doubled up by telling the generator where the main column really is.

这篇关于外键导航属性命名约定的替代品的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！