Question

这是一个很难提出/询问的问题。我问的是内存使用和执行的效率。该应用程序正在使用ASP.NET MVC。我在C＃的标题virtual和VB的标题overridable中加入了标题，因为我认为该语言对这个问题没有影响。

代码具有UI/controller/domain/storage分层体系结构。在存储层中，使用以下模型设计：

StorageParent

StorageChild
  public virtual StorageParent StorageParent { get; set; }
    --OR---
  Public Overridable Property StorageParent As StorageParent

StorageGrandchild
  public virtual StorageChild StorageChild { get; set; }
    --OR---
  Public Overridable Property StorageChild As StorageChild

这允许StorageGrandchild通过Grandchild.Child.Parent.ParentID访问StorageParent的ID。但这是在存储层中。

在Controller / UI层中需要访问层次结构中的所有ID。但是我不确定使用“域”层从孙子提供到父级的路径的正确方法。

如果我在如下所示的域中声明一个属性，是否只是创建对父项的引用，还是实际上保留了额外的内存以及随之而来的必要时间，以便为整个父项在Domain layer Child record中传输数据记录，和孙子一样吗？在这种情况下，virtual/overridable关键字不适用于这里，是吗？

Parent

Child
  public virtual Parent Parent { get; set; }
    --OR---
  Public Overridable Property Parent As Parent

Grandchild
  public virtual Child Child { get; set; }
    --OR---
  Public Overridable Property Child As Child

之所以触发我的问题，是因为我认为virtual/overridable关键字仅用于在EF上下文中提供导航，并且这种导航功能在EF上下文之外定义的模型（例如域层代码）中不存在

我只需要访问ParentID，而不是整个记录。我是否应该在域记录中将不同的ID记录定义为Integer，如下所示：

Parent

Child
  ParentID

Grandchild
  ChildID
  ParentID

还是可以使用定义为父级的属性而不使用额外的内存并浪费执行时间？

Answer 1

它实际上是否保留了额外的内存

从某种意义上说是的。引用本身（作为已编译的代码）不会占用太多内存。但是要使Grandchild.Child.Parent.ID正常工作，必须同时加载Child和Parent，这比具有两个ID值的Grandchild占用更多的内存。旁注：我认为Grandchild.Child.Parent.ParentID是一个错字，应该是Grandchild.Child.Parent.ID。如果是这样，Grandchild.Child.ParentID将具有相同的效果。

在这种情况下，虚拟/可覆盖关键字不适用于此处

virtual关键字用于启用延迟加载。它触发EF将实体具体化为覆盖virtual导航属性的延迟加载代理对象。综上所述：延迟加载是数据访问层的概念。您可能想在域层中设置属性virtual，但这并不是出于那个的目的。

我应该在域记录中将不同的ID记录定义为Integers

在域层中，您不想使用ID值，因此很容易：不。是否要GrandChild对其Child的{{1}}进行冗余引用取决于您。经验法则：避免冗余。

因此，从域的角度来看，最后，是的，加载引用并理所当然地考虑内存开销。

但是，问自己一个问题，将实体对象复制到域对象中的耗费内存（和时间！）的操作是否真的值得吗？

EF存储上下文中的虚拟/可覆盖属性功能是否在域层中以相同的方式存在？

1 个答案: