需要实体框架类/数据库架构建议

本文关键字：数据库 构建 实体 框架 | 更新日期: 2023-09-27 18:10:34

我最近问了一个问题，坦率地说，从给出的答案来看，我正在重新考虑我的整个策略/我如何设计类和数据库。

我还没有在我的任何实体框架项目中使用过虚拟关键字，也没有使用过Icollection，而且坦率地说，在阅读了一些示例之后，我不完全理解为什么需要它，或者它是如何工作的。

在一个示例应用程序中，我有一个简单的设计，其中有三个列表-人，笔记和图片。这种关系是这样的，一个人可以拥有多个笔记和图片，以及一个人的标志是一个图片。 
   public class Person
    {
        public int ID { get; set; }
        public string name { get; set; }
        public Picture logo { get; set; }
    }
    public class Note
    {
        public int ID { get; set; }
        public string Text { get; set; }
        public Person Owner { get; set; }
    }
 public class Picture
    {
        public int ID { get; set; }
        public string Path { get; set; }
        public Person Owner { get; set; }
    }

当我想要选择一个人拥有的笔记列表时，我只需在notes对象上执行db.Notes.Where(x=>x.owner=="y")。我想我明白，如果我要在person类上使用iccollection，我可以按照db.person.select(x=> x.notes)的行来执行一些操作来检索所有的笔记。我这样想对吗?

如果你在我的位置与上面的相对简单的例子，你会如何构建类(涉及到ICollection, virtual或其他)?

此外，最重要的是，上面只是一个例子，但是在我的实际应用程序中，我使用了一个非常相似的结构，其中我使用自定义类型作为"连接器"/外键。

在我读过的许多例子中，(在上面的例子中)他们将使用public int OwnerID而不是public person Owner。这真的让我很困惑，我开始质疑我的整个EF战略。有什么不同?

需要实体框架类/数据库架构建议

我认为你让这件事变得更困难了。如果你在布置常规的类，你应该把它们彼此关联起来，而不是像你在例子中那样找到相关的id并分别加载它们。

public class Person 
{ 
    public int ID { get; set; } 
    public string name { get; set; } 
    public ICollection<Note> Notes { get; set; }
    public ICollection<Picture> Pictures { get; set; }
    public Picture logo { get; set; } 
} 
public class Note 
{ 
    public int ID { get; set; } 
    public string Text { get; set; } 
    public Person Owner { get; set; } 
} 
public class Picture 
{ 
    public int ID { get; set; } 
    public string Path { get; set; } 
    public Person Owner { get; set; } 
}

现在假设你使用查询

获得了person对象
var person = _context.People.Where(m=>m.ID=randomIntWeWant).First();

我们可以获得所有相关的项目作为属性。

指出

person.Notes

照片
person.Photos

ICollection与延迟加载有关。通过在一侧将属性声明为ICollection，您可以说对象之间具有多对一关系。如果你在两边都声明一个属性为ICollection，你就是在说它是一个多对多关系。EF负责创建跟踪这种关系的表。

相关文章：