一、单向导航属性引入

1.双向导航属性存在的问题：数据库中存在一些“基础表”，这些表会被其他各种表来引用。比如有一张User表，另有请假表（请假人、审批人）、采购表（采购员、审核员）等多个表的多个属性都会引用这一张表。那么对于User这个实体，当中就会引用所有表实体作为导航属性，从而造成User表臃肿。
2.观察前文的两个实体：
主体实体文章Article：

public class Article
{public long Id { get; set; }public string Title { get; set; }public string Message { get; set; }public List<Comment> Comments { get; set; }
}

依赖实体评论Comments：

public class Comment
{public long Id { get; set; }public string Message { get; set; }; }public int ArticleEntityFkId { get; set; }public Article TargetArticle { get; set; }
}

在Article中可以通过Comments属性找到相对应的评论实体。而在Comment中也可以通过ArticleEntityId来找到对应的文章。但是在大多数情况下，我们只需要通过Article来找Comment即可，很少有通过Comment来找对应的Article。也就是说，我们希望导航属性只要能通过A“单向”的找到B即可，B并不需要任何属性去“发现”A。
通过1、2两点明确双向导航属性在某些情况下会遇到如下问题：
第一，业务不需要 第二，代码臃肿
因此，可以使用单向导航属性来解决这些问题。

二、单向导航属性

1.什么是单向导航属性：在两个关联实体A与B中，A中含有 导航属性b能够找到关联的B实体或实体集合，但是B中不含有任何能够找到主体实体A的导航属性。此时称b为单向导航属性。例如Article中的Comments。
2.配置单向导航属性：
(1)使用约定只能使用（主体实体名+主体实体主键名）一种方式构建一对一的单向导航属性。但是显然不适合文章与评论的情景。需要使用FluentAPI进行手动配置。
(2)使用FluentAPI进行配置依旧使用HasXXX()、WithXXX，其与双向导航属性配置的区别就在于HasXXX/WithXXX只需要指定一个方法的参数，也就是含有导航属性的实体的参数即可，另外一个不需要给定任何参数。

主体实体文章Article：

public class Article
{public long Id { get; set; }public string Title { get; set; }public string Message { get; set; }public List<Comment> Comments { get; set; }
}

依赖实体评论Comments：

public class Comment
{public long Id { get; set; }public string Message { get; set; }; }public long ArticleEntityFkId { get; set; }
}

这里Atricle与Comments是一对多的关系，且单向导航为Article指向Comment。只需要在Article中指出导航属性为Comments，而Comment在关系配置中不需要给定任何参数：

执行数据迁移：

可以看到已经成功生成了对应的外键。
但是使用单向导航属性就不能说配置在哪一端都可以了，必须配置在含有导航属性的一端（配置在另一端干脆就找不到导航属性，从而也无法配置导航属性）

三、如何选择使用单向导航属性还是双向导航属性

1.对于主从结构的“一对多”表关系，一般使用双向导航属性
2.对于其他的一对多关系：
(1)若本表是被很多其他表引用的基础表，使用单向导航属性
(2)其他情况下可自由决定是否使用单向导航属性