哪种设计模式适合将关系数据转换为领域模型？

Question

问题

我有一些代码可以将以关系形式存储的数据转换为域模型。源不是 RDBMS，而是一组生成的“表”类。这些表类可与java.sql.ResultSet 进行比较，每个表类代表一组数据：订单、订购商品、交货、发票、序列号。

转换代码通过遍历表从头开始创建域模型的层次结构。它创建适当的模型对象，将它们连接到其他模型对象等等。完成后，它会返回领域模型（订单列表）。

问题是转换代码都被塞到一个类中，涵盖了数据的不同方面，因此很难进行单元测试、查找错误或扩展它。我需要维护这段代码多年，真的很想以某种方式拆分它，但我不确定哪种设计模式可以很好地应用在这里。

想法

我倾向于将代码重构为访问者模式：

• 引入一个容器类来公开对表对象的引用（例如getOrdersTable()、getOrderItemsTable()）
• 为此容器类创建多个访问者类。每个访问者都涵盖了源数据的一个方面：一个是自己创建订单对象，另一个是创建交付对象并将它们连接到相应的订单对象中，等等。

但是，我不确定以下问题：

• 访问者不仅可以使用他们访问的表对象，还可以使用其他访问者创建的对象（后者都可以通过作为域模型根的订单列表访问）。因此，调用访问者的顺序很重要。
• 访问者模式通常在节点层次结构的上下文中进行解释，但我不会让它们访问层次结构，他们会创建一个层次结构。

问题

1. Visitor 是一个不错的选择，还是您会选择另一个众所周知的模式？或者这是没有设计模式适用的情况，我应该避免（错误）使用模式术语？

2. 以上任何问题对于访问者来说是否异常？如果是这样，您认为无论如何实现 Visitor 会使代码混乱吗？毕竟，模式是为了匹配直观的期望并提高代码的意义。

上下文信息

• 我可以安全地向表类添加方法（每个都包含一个抽象生成类和一个用于手动修改的子类）或让它们实现接口，但不能修改它们的公共超类或引入新超类。
• 表集相对稳定，但可能会添加新列。此外，转换逻辑本身也有一定程度的变化（例如，跳过哪些订单，或映射数据的特殊情况）
• 领域模型本身比较干净，我无意以非向后兼容的方式更改它，甚至完全替换它。
• 这是关于 Java 代码的。
• 不需要线程安全。

Answer 1

如果你还没有，我建议你买一本 Martin Fowler 的书Patterns of Enterprise Application Architecture

您所说的访问者模式实际上是一种将操作应用于已经以某种方式结构化的对象的模式 - 正如您所说的那样，您还没有。

在 Martin Fowler 的术语中，我认为您想要的是 Data Mapper，它与您当前的实现类似。

对我来说，诀窍是确保在编写实现时考虑到可维护性和可测试性。您可能想练习一些 TDD 来帮助您实现目标，但总而言之，我认为您应该看看可以将哪些功能分离到可以简单地进行单元测试的“帮助”类中

例如，您可能决定为每个“表”设置一个数据访问对象，离开主 DataMapper 类来控制域模型的最终构造

Answer 2

域对象或业务对象模式将满足您的需要。

请通过业务对象 http://www.corej2eepatterns.com/Patterns2ndEd/BusinessObject.htm

如果您的应用程序本质上更复杂，则使用域存储模式

http://www.corej2eepatterns.com/Patterns2ndEd/DomainStore.htm