何时在模型中创建导航属性答案

【问题标题】：When to create a navigation property in model何时在模型中创建导航属性
【发布时间】：2014-09-17 23:30:30
【问题描述】：

作为一名新程序员，我试图了解何时应该为我的模型创建导航属性。有什么取舍？

在极端情况下，模型可以只包含任何字段需求，还是基础模型可以为每个字段提供导航属性？

或者导航属性是否应该只用于复杂的相关实体（具有多个属性的实体）？

我正在考虑的另一个考虑因素是最适合 MVC 下拉或 jquery 自动完成的方法。设计模型将如何影响应用程序和 sql 性能？

public class Vendor 
{
    public int ID { get; set; }
    public string Name { get; set; }
    public string Number { get; set; }
    public string Address { get; set; }
    public string City { get; set; }
    public string State { get; set; }
    public string PostalCode { get; set; }
    public string Country { get; set; }
}

或者我可以这样做并假设相关表也存在于命名空间中，进而存在于数据库中。

public class Vendor 
{
    public int ID { get; set; }
    public virtual Name Name { get; set; }
    public virtual Number Number  { get; set; }
    public virtual Street Street { get; set; }
    public virtual City City { get; set; }
    public virtual State State { get; set; }
    public virtual PostalCode PostalCode { get; set; }
    public virtual Country Country { get; set; }
}

我可以看到，一些相关实体在本质上是静态的，例如 States，但 Number 和 Street 会随着时间的推移而增长。

【问题讨论】：

我想你可能误解了导航属性Relationships and Navigation Properties。第一个模型很好，但第二个模型没有意义，因为Name、Number 等不是复杂的对象，也没有数据库中的相关表。但是，您可能拥有包含地址属性的类 Address，然后 Vendor 将拥有 int ID、string Name 和 int AddressID、virtual Address Address
斯蒂芬，我假设相关的表/属性存在于命名空间/数据库中。我将它们排除在外以保持问题简短。
既然说属性Number 是一个字符串或整数，你为什么要为Numbers 提供一个单独的表？单独的Addresses 表可能会感觉到您是否有可能为供应商提供多个地址。

标签： asp.net-mvc entity-framework entity

【解决方案1】：

如果您的属性可以用一个简单的数据库列表示，那么您使用第一种方法，如果您的属性本身有自己的属性，那么您将需要一个导航属性。如果您的情况，如果 City 还具有诸如 Id、Name 等属性，那么您将使用导航属性，但是，如果您只想将 city 作为名称存储，您的第一种方法将起作用。

【讨论】：