问题标签 [persistence-ignorance]

我已经简要介绍了 NHibernate 和 Linq2Sql。我也打算看看实体框架。

当我谈到这些 ORM 时，提出的问题是“它们无法扩展”，那么它们可以吗？从谷歌我得到的印象是他们能够很好地扩展，但最终我认为必须付出代价，是否值得为更丰富、更简单的业务层付出代价。

我是 DDD+TDD 世界的新手。但我从事编程工作将近 9 年了。

有人可以解释一下坚持无知的好处吗？典型的 nHibernate 应用程序只是将类和数据库之间的依赖关系推送到映射文件。

如果我更改类文件或数据库，我必须更改映射文件。那么它不只是通过添加一个抽象层来推动依赖吗？在我看来，到目前为止，我不认为这是革命性的。但我不确定我是否遗漏了什么。

最后如何测试映射文件？映射文件中可能会出现错误，我该如何测试它们？

我有一个现有的域层。我想使用 Linq to SQL 开发持久层。我目前正在使用外部地图文件。我正在尝试对我的子集合使用延迟加载，但没有成功。有没有办法使用 Linq to SQL 但不使用 EntitySet 或 EntityRef 来实现延迟加载。

我已经实现了一个不知道持久性的存储库模式。存储库实现仅与我的实体对象IUnitOfWork和ITable<T>接口交互。目的是IUnitOfWork不重用，而是代表单个事务。到目前为止，我已经实现了 in-memory 以及 Linq-to-Sql 的IUnitOfWorkand版本ITable<T>。

我的问题是，由于IUnitOfWork注入到存储库中，我最终需要知道如何IUnitOfWork在使用存储库的地方实例化一个新的。由于这是应该可以插入的主要部分，所以感觉就像我做错了什么。一般的使用模式是这样的：

现在看来，我需要一些其他模式来允许应用程序中的每个存储库使用来获得正确的工作单元（例如内存中、L2S 等）。

最适合这个的模式是什么？我看过福勒关于这个话题的讨论，但他的例子似乎都不是完全合适的。我已经觉得我拥有的抽象量比我想要的要多，所以构建另一个间接性似乎过度了。

目前，我倾向于某种应用程序范围的提供程序，它可以配置为生成正确的IUnitOfWork. 我是偏离基地还是这是真正实现不可知论所需要的？

我正在尝试将我的域模型尽可能地写成持久性无知。我现在唯一要做的就是标记每个属性和方法virtual，因为 NHibernate 要求延迟加载。

在我的域模型程序集中，我定义了一些存储库接口：

然后我有一个数据汇编。这个将引用 NHibernate，它知道它的存在。这是实现这些存储库接口的程序集：

等等。

现在我想为我的存储库实现一个事务功能。为此，我将BeginTransaction在 IRepository 接口上添加一个方法。但是，我不能将它的返回类型定义为NHibernate.ITransaction，因为我想保持域模型持久性无知，而不是被迫从我的域模型程序集中引用 NHibernate 的程序集。

你会怎么办？

您是否会简单地在接口上实现 a void BeginTransaction()、 avoid Commit()和 avoid RollBack()方法，并让存储库实现在ITransaction内部管理对象？

或者您会找到一种方法来公开ITransaction对象以让客户端直接使用它来管理事务，而不是使用存储库的方法？

谢谢！

持久性无知通常被定义为持久化和检索标准 .NET 对象（或 POCO，如果你真的坚持给它们命名）的能力。标准 .NET 对象的一个​​看似广为接受的定义是：

“...普通课程，您专注于手头的业务问题，而不会出于与基础设施相关的原因添加内容...”

然而，我看到人们将 NHibernate 描述为一个允许忽略持久性的框架，但它是一个不能在任何标准 .NET 对象上工作的框架，只能在符合特定设计要求的标准 .NET 对象上工作，例如（来源）：

• 所有类都必须有一个默认构造函数
• 除非类未密封并且所有成员都是虚拟的，否则某些功能将不起作用
• 除非您滥用 Equals/GetHashCode，否则对象标识无法正常工作

（旁白：在任何人不高兴之前，我并不是要在这里选择 NHibernate，它只是一个经常被引用的框架示例，据称它允许持久性无知。我确信类似的论点可以应用于其他声称相同的 ORM .)

现在，尽管该类本身没有任何持久性框架特定的属性或基类等，但对我来说，它并不是真正的“不了解持久性”，因为它必须遵循一组设计准则以方便所选持久性框架的使用。您必须考虑到持久性框架的要求来设计和实现该类；如果您对此一无所知，则该课程可能无法使用。

我对“持久性无知”/“POCO”的定义有疑问的地方是，我不明白从概念上讲，这与添加属性（例如[Serializable]or [DataContract]or[XmlType]或任何其他持久性框架特定的注释）有什么不同这有助于使用该框架的实体的持久性和检索。

那么，究竟什么是“执着无知”呢？

显然，将其定义为能够持久化“普通类”是一个谬误，因为 NHibernate 仅在不引用特定于框架的类方面是普通的，而它们是非凡的，因为它们需要不寻常的设计选择，例如默认构造函数和所有- 可变类型的虚拟成员和 Equals/GetHashCode 实现。

因此，当对象有助于使用持久性框架（在设计和结构中或通过使用特定于框架的注释）但本身不执行任何持久性逻辑时，是否可以合理地说“持久性无知”是正确的？

让我们考虑典型的Order和OrderItem示例。假设OrderItem是Order Aggregate 的一部分，它只能通过 Order 添加。因此，要向 Order 添加新的OrderItem ，我们必须通过 Repository 加载整个 Aggregate，向Order对象添加新项目并再次持久化整个 Aggregate。

这似乎有很多开销。如果我们的Order有 10 个OrderItems怎么办？这样，仅仅添加一个新的OrderItem，我们不仅要读取 10 个OrderItems，而且我们还应该重新插入所有这 10 个OrderItems。（这是 Jimmy Nillson 在他的 DDD 书中采用的方法。每次他想要持久化一个 Aggregate 时，他都会清除所有子对象，然后再次重新插入它们。这可能会导致其他问题，因为孩子的 ID 是由于数据库中的 IDENTITY 列，每次都更改。）

我知道有些人可能会建议在聚合根中应用工作单元模式，以便跟踪已更改的内容并仅提交这些更改。但这违反了持久性无知 (PI) 原则，因为持久性逻辑正在泄漏到领域模型中。

有没有人考虑过这个？

莫什

我第一次在一个小项目上尝试使用 POCO 的 EF 4。在我的 Repository 实现中，我想提供一个 AddOrUpdate 方法，如果它是新的，它将向存储库添加传入的 POCO，否则什么都不做（因为在调用 SaveChanges 时将保存更新的 POCO）。

我的第一个想法是这样做：

但是，这会导致参考不支持NotSupportedException的非标量变量（额外问题：为什么不支持？）

只需删除该Contains部分并始终调用 AddObject 会导致InvalidStateException：

ObjectStateManager 中已存在具有相同键的对象。现有对象处于未更改状态。只有处于添加状态的对象才能再次添加到 ObjectStateManager。

很明显，EF 4 在某处知道这是基于密钥的副本。

当调用 AddOrUpdate 以便随后调用 SaveChanges() 时，存储库为新的或预先存在的对象更新 Pocos 的一种干净、有效的方法是什么？

我确实考虑过在对象本身上携带一个 isNew 标志，但我试图尽可能地考虑持久性无知。

我是 ASP.NET MVC 的新手，来自 PHP MVC 背景。这是一种尴尬的过渡（请参阅我的问题历史，呵呵。）

在.Net 世界中，我在理论上非常喜欢的一件事是模型与持久性无关的想法。但是在这种情况下，将更改保存到模型的正确方法是什么？在 PHP 中，我只是$model->save();在进行一些转换后调用。在 C# 中，我不确定如何做到这一点。

这合适吗？

我想唯一让我觉得错误的是，通常情况下，我不希望控制器以这种方式直接访问数据访问层。以前，在 PHP 领域，我的控制器基本上只能访问模型和视图。

我会修改带有关联集合的分离实体，例如：

人员和地址是 POCO。

当我附加实体并保存更改时，未检测到集合更改，如何使用地址更新人员（添加和删除的项目）？

我要手动跟踪我的收藏吗？

编辑

分离的 POCO 的同步必须是手动的...... EF 不打算合并集合的解决方案（导航属性和关系）:(

我比较当前和原始集合并发现差异