Question

ORM经常映射一对多关系，例如：

class Parent {
   IList<Child> Children { get; set; }
}

问题是在存储库中，您可能有：

GetChildrenOfParent(int parentID) {
   from c in Children...

   return children;
}

你现在有两个地方可以“得到”孩子。当您想要添加某些内容时，例如可能只返回没有删除标记的子项，您可能需要：

GetChildrenOfParent(int parentID) {
    from c in Children..
    where not deleted

    return children;
}

或

class Parent {
   IList<Child> Children { get .... only get not deleted children; set; }
}

你看到我得到了什么吗？您现在有两个地方可以选择执行getter例程。似乎这个例程的逻辑位置在存储库中，但这意味着：

foreach (var child in parent.Children)

不再通过你的“getter”了，因此ORM以这种方式映射的一对多的整体想法似乎是错误的？

Answer 1

我不确定你的问题是什么，但我真的不知道它在哪里'错了'。它归结为设计选择IMO。是否要从每个实体访问分层数据（子实体）。如果您这样做并且您希望在初始提取中加载该数据，那么使用一对多可以节省时间（您可以选择预加载它或延迟加载它）。在这种情况下，在第一个示例中获取数据可能对您有好处。您可以使用LINQ过滤数据，只返回“未删除”结果或“您需要的任何过滤器”，如下所示：

IList<Child> list = parent.Children.Where(x => x.Deleted == false);

就我个人而言，我喜欢保持清洁，当我使用存储库模式时（我最近成为了ActiveRecord模式的忠实粉丝）。我更喜欢把它分成它自己的方法调用。您可以将存储库调用添加到属性名称children中，但对于我来说，感觉就像我在模型之间和我正在模仿该模型之间的界限。

但是这样做有时候会结束一大堆方法来进行基本过滤或愚蠢的一堆或重载来管理你想要选择“删除或不删除”和“男性或女性”或只是'删除与否'。

正如我所说，归结为选择。您希望自己的应用程序如何发展，如果您认为最终会在存储库中列出一些愚蠢的重载，那么您可以使其更清晰，以便将来的编码人员能够理解您的代码，管理的代码更少，而且不会干扰性能（或使其在理想情况下表现更好）。在这种情况下，进行测试将帮助您重构而不会破坏代码。

不要挂在“正确”或“错误”的做事方式上。

存储库模式，orms，以及getter和setter

1 个答案: