6

我有一个相当深的对象层次结构，我试图通过 Entity Framework 4、POCO、PI（持久性无知）和 Code First 来坚持。突然间，当我意识到不使用 new() 操作符时，事情开始运转良好。如最初所写，对象经常使用 new() 来创建子对象。

相反，我使用我对存储库模式的看法来根据需要创建所有子对象。例如，给定：

class Adam
{
  List<Child> children;
  void AddChildGivenInput(string input) { children.Add(new Child(...)); }
}

class Child
{
  List<GrandChild> grandchildren;
  void AddGrandChildGivenInput(string input) { grandchildren.Add(new GrandChild(...)); }
}

class GrandChild
{
}

（“GivenInput”意味着此处未显示一些处理）

我定义了一个AdamRepositorylike：

class AdamRepository
{
    Adam Add() 
    { 
        return objectContext.Create<Adam>(); 
    }
    Child AddChildGivenInput(Adam adam, string input) 
    { 
        return adam.children.Add(new Child(...)); 
    }
    GrandChild AddGrandchildGivenInput(Child child, string input) 
    { 
        return child.grandchildren.Add(new GrandChild(...)); 
    }
}

现在，这已经足够好了。但是，我不再“不了解”我的持久性机制，因为我已经放弃了 new() 运算符。

此外，我面临着一个贫乏的领域模型的风险，因为如此多的逻辑最终在存储库中而不是在域对象中。

告别后，一个问题：

或者说几个问题...

  • 使用 EF 4 Code First 是否需要此模式？
  • 有没有办法保留使用 new() 并且仍然使用 EF 4 / POCO / Code First？
  • 是否有另一种模式可以将逻辑留在域对象中并且仍然可以使用 EF 4 / POCO / Code First？
  • 在 Code First 支持的更高版本中会取消此限制吗？

有时尝试走 POCO / Persistence Ignorance 路线感觉就像在上游游泳，有时感觉就像在尼亚加拉瀑布游泳。尽管如此，我还是愿意相信...

4

1 回答 1

4

以下几点可能有助于回答您的问题：

在您的类中，您有一个用于子集的字段和一个添加到子集的方法。一般来说，EF（不仅仅是 Code First）目前要求集合是表面作为属性，因此目前不支持这种模式。EF 的常见要求是我们如何与类交互更加灵活，我们的团队目前正在研究如何支持这一点

您提到您需要在上下文中显式注册实体，这不一定是这种情况。在下面的示例中，如果 GetAdam() 返回附加到底层上下文的 Adam 对象，那么当您保存并插入数据库时​​，EF 将自动发现新的子 Cain。

var adam = myAdamRepository.GetAdam();

var 凯恩 = 新的孩子（）；

adam.Children.Add(该隐);

〜罗文

于 2010-06-14T23:20:26.810 回答