java - 在不同的 Spring 数据存储库中使用相同的实体类

Question

我正在尝试构建一个项目，在该项目中我必须使用不同的 Spring 数据存储库(gemfire、jpa、mongodb 等)来保存一些实体类。由于需要进入这些存储库的数据或多或少相同，我想知道是否可以对所有这些存储库使用相同的实体类来避免从一个对象转换为另一个对象？

我让它适用于 gemfire 和 jpa，但实体类已经开始看起来有点有线了。

@Id // spring-data-gemfire
@javax.persistence.Id // jpa
@GeneratedValue
private Long id;

到目前为止我可以看到以下选项:

1. 创建基于单独实体(域)类的接口(interface) - 尝试重复使用同一类看起来有点过早优化。
2. 外部化基于 xml 的 JPA 映射，不确定是否可以外部化 gemfire 和 mongodb 映射。
3. 使用不同的具体实体类并使用一些复制构造函数/转换器进行转换。

我一直在用头撞墙来寻找最好的方法 - 非常感谢任何回应。谢谢

Answer 1

如果很奇怪，您的意思是您的应用程序域对象/实体类开始积累许多不同但独立的(映射)注释(有些语义甚至相同，例如 SD Common 的 o.s.data.annotation.Id 和 JPA 的 @javax.persistence.Id )这些实体将被持久保存在不同的数据存储中，那么我认为这是可以理解的。

随着实体表示数量的增加，注释污染也会增加。例如，考虑用于 JSON 映射的 Jackson 注释或用于 XML 的 JAXB 等。很快，您就会拥有比实际数据更多的元数据，:-)

然而，这更多的是一个偏好、方便、简单的问题，真的。

一些开发人员是纯粹主义者，喜欢将所有内容外部化。其他人喜欢将信息(元数据)保存在靠近使用它的代码的地方。甚至已经出现了某些模式来解决这些类型的问题...DTO、限界上下文(请参阅 Fowler 的 BoundedContext，它与 DDD 和微服务有很强的相关性)。

就个人而言，我在代码中设计和应用架构原则/决策时使用以下规则，尤其是在引入新内容时:

1. 简单
2. 一致性
3. 干
4. 测试
5. 重构

(以及其他一些......良好的 OOD、SoC、SOLID、设计模式等)。

也是按照这个顺序。如果某些事情开始变得过于复杂，请重构并简化它。通过遵循/使用模式、惯例来保持你所做的事情的一致性；熟悉度是一致性的关键之一。但是，也不要一直重复自己。

归根结底，这实际上是关于维护应用程序。接续你停下的地方的其他人是否能够快速理解码织和逻辑，并能够维护它……简单就是王道。这并不意味着它太简单了，不可行或不有值(value)。如果组织得当，即使是复杂的事情也可以变得简单。然而，将事物分解并引入抽象可能会产生隐性成本(请参阅结束语)。

为了更具体地回答您的(一些)问题......

我不确定 MongoDB，但是(Spring Data)GemFire 没有外部映射。至少，@Region (在实体类上)和 @Id是必需的，以及 @PersistenceConstructor如果你的实体类有超过 1 个构造函数。对于 example .

对于 DTO 来说，这听起来有点像。就我个人而言，我认为 BoundContext 是应用程序数据的更好、更自然的模型，因为域模型不应过度依赖于任何持久存储或外部表示(例如 JSON、XML 等)。应用程序域模型是应用程序的第一个真实状态，它应该对以自然方式表示的概念进行建模，而不是表面上满足某些表示或持久存储(因此是映射/转换)。

无论如何，尽量不要太自责。这一切都是为了管理复杂性。尝试让自己去做并使用测试和其他反馈循环来找到适合您的应用程序的答案。你就会知道。

希望这有帮助。