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

问题描述

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

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