为什么这么多的程序员绝对讨厌对象普遍性层？

流行是一种简单的技术，可基于二进制序列化和预写日志记录为内存中的对象模型提供ACID属性。它是这样的：

• 从快照开始。序列化对象模型并将其写入文件。
• 创建日记文件。对于对对象模型的每次调用，请序列化该调用及其参数。
• 当日志太大时，您将要关闭，或者它很方便，请执行检查点：编写新快照并截断日志。
• 要回滚或从崩溃或停电中恢复，请加载上一个快照并重新执行日志中记录的所有调用。

进行此工作所需的预防措施为：

• 不要让易变的对象引用转义或进入流行层。您需要某种代理或OID方案，就像在进行RPC一样。（这是一个常见的新手错误，被昵称为“ 洗礼问题 ”。）
• 调用可到达的所有逻辑都必须是完全确定性的，并且不得执行对业务逻辑有意义的I / O或OS调用。写入诊断日志可能没问题，但是获取系统时间或启动异步委托通常不行。这样一来，即使在不同的计算机上或在不同的时间还原日志，日志也可以相同地重放。（大多数流行代码提供备用时间调用以获取事务时间戳记。）
• 作者并发在日记解释中引入了歧义，因此被禁止。

是因为...

• 人们试图在一个不太适合^*的项目中使用它之后，对他们产生了不良品味？
• 克劳斯·威斯特费尔德（Klaus Wuestefeld）的强烈倡导 使人们无法接受？
• 喜欢命令式编程模型的人不喜欢将I / O与计算分离，而宁愿将计算与I / O和线程调用交错？
• 流行层在概念上是如此简单，并且与它们所居住的框架的特性紧密相关，以至于它们通常是针对项目定制的，这使它们过于陌生/不合标准/充满风险？
• 保持直截了当是很困难的，您必须注意不要这样做？
• 新手的脑袋似乎在遇到与他们在学校学会编写的不是两层数据库驱动的应用程序相同的东西时爆炸吗？;）

^*在RAM中整个数据集拟合，你不需要作家的并发，并且你不需要做即席查询，报表，或导出到数据仓库。通过对SQLite的歉意，普遍性是对保存文件的一种改进，而不是Oracle的替代。

我认为一些问题是他们有一个非常特定的用例（您不适当的理由）。我已经在使用这种方法的系统上进行了构建和工作，当您遇到的问题实际上是一个问题时，它可能是一个很好的解决方案。

另一部分是，它看起来很像您在10年前发现的一些更痛苦的自定义数据存储区，并且具有一些相同的陷阱（例如，考虑批量更新btreive），这使您“太过习惯”这一点，但也使得很难找到与之礼貌相处的现成零件。

最后一部分是，在许多情况下很难对他们进行查询，而且一般而言，人们非常习惯于现在能够获得他们的答案。

我认为您首先需要证明很多开发人员绝对讨厌他们。我认为并非如此。考虑一下福勒，前不久在这里为此确定了一种形式的模式。

问题的答案是，尽管理论很简单，但实践却并非如此。

仅仅测试这样的设置需要数十个测试用例，添加多进程或多线程代码，这会跳转到数百种可能需要测试的条件，以实现持久性和恢复性。

任何事务监控器，例如CICS，Tuxedo，Weblogic，Websphere，JBOSS或.NET，都将以干净且经过测试的方式提供所有这些功能。任何数据库都可以为大多数应用程序提供“足够的”事务/持久性。

它的大部分情况是很久以前就发明和完善的。

前提条件听起来有点麻烦，尤其是对于大多数在内存中运行且不需要ACID的系统。开销听起来也有点令人讨厌-那里涉及许多状态跟踪。