域模型随序列化而变化

Question

我希望对如何处理域序列化后域模型更改的方案有一些看法。就像在项目中一样，我们在Marklogic数据库中以XML格式保存pojos。它是我们的一种恢复商店。

但是我们的pojo模型可能会有一些变化，即字段级别更改的某些层次结构更改。所以，如果我将尝试从我们的数据库中恢复。它会破裂。

那我该如何处理这种情况呢？

Answer 1

查看问题的一种方法是完全是一个应用程序/ Java级别的问题。假装没有涉及数据库，您的应用程序打算如何管理2个数据模型的共存？ ＆＃39; DTO或对象/对象映射是处理此问题的一种方法。例如。使用像http://mapstruct.org/ http://dozer.sourceforge.net/ https://github.com/FasterXML/jackson这样的库 - 您可以定义POJO版本之间的映射并在运行时转换它们。这解决了问题，但是错过了MarkLogic不仅仅是一个简单的POJO商店的潜力。

与Johns的答案类似，另一种看待这种情况的方法是，以您描述的方式使用MarkLogic（仅作为序列化POJO的方式）并不能有效地利用其功能。 MarkLogic既是一个应用服务器又是一个数据库。通过使用少量服务器端代码，您可以实现一个稳定的界面，该界面可以支持各种格式并随您的应用程序一起发展。这也可以让你卸载＆＃39;处理到服务器，通常可以实现显着的性能改进。存储在服务器中的数据格式不需要以任何方式与应用程序发送或接收的格式相似。

当您执行需要多个对象的操作时尤其如此。在应用程序层 - 如果您使用传统的RDB ORM（对象关系映射）模型与MarkLogic并将POJO的1：1映射到Document，您将错过在服务器上组合和重构操作的机会，并且经常需要提出许多请求执行可以在一个人做的事情。不仅有多个请求的开销，而且ML中的许多操作在不受限于必须存储与应用程序对象1：1建模的DB对象时效率明显更高。

如果在应用程序中将界面移动到ML up层或更多层，则可以在服务器而不是客户端上执行业务逻辑，而不是在服务器上存储最低级别的POJO，而是实现＆ ＃39;服务＆＃39;模型。这通常会显着提高性能，减少代码大小。

Answer 2

MarkLogic本质上是一个无模式的NoSQL存储，这意味着试图强制它的模式并期望它永远不会改变（就像一个具体的POJO模型）将打败这个想法。如果您希望保持灵活性并允许随着时间的推移进行架构修改，我可以提出一些建议：

1. 您仍然可以为您知道将保持架构一致的文档序列化/反序列化POJOS
2. 您可以检索具有未知结构的xml文档，并使用DOM解析器或使用Java+XPath来检索您需要的数据
3. 我的首选解决方案：直接连接到MarkLogic XQuery API（使用XQJ或类似工具）并直接读取文档。更多信息here。

Answer 3

将版本控制放在XML中。任何体面的POJO序列化都应该支持，或者你可以在进入MarkLogic的过程中添加它。

反序列化XML时，请查看版本并路由到了解该版本的XML库函数。这可以在MarkLogic或其他XQuery或XSLT处理器中完成。