外键导航属性命名约定的替代品

本文介绍了外键导航属性命名约定的替代品的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

在使用实体框架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.