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

Question

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

我让它为gemfire和jpa工作，但是实体类已经开始看起来有点连线了。

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

到目前为止，我可以看到以下选择：

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

为了找到最好的方法，我一直在用头撞墙--任何回应都很感激。谢谢

Answer 1

如果您所说的怪异，意味着您的应用程序域对象/实体类开始为这些实体将持久化的不同数据存储积累许多不同但独立的(映射)注释(一些语义相同甚至是相同的，例如SD公共的o.s.data.annotation.Id和JPA的@javax.persistence.Id)，那么我想这是可以理解的。

注释污染只会随着实体的表示数的增加而增加。例如，想想JSON映射的Jackson注释或XML的JAXB等等。很快，您就有了比实际数据更多的元数据：)

然而，它更多的是一个偏好，方便，简单，真的。

有些开发人员是纯粹主义者，喜欢将一切具体化。其他人喜欢将信息(元数据)与使用它的代码保持在一起。甚至出现了一些解决这些问题的模式.DTO，有界上下文(参见Fowler的BoundedContext，它与DDD和Microservices有很强的相关性)。

就我个人而言，在设计和应用代码中的架构主体/决策时，特别是在引入新的内容时，我使用以下规则：

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

(和其他一些人一样.良好的OOD，SoC，实心，设计模式等)。

也是按照这个顺序。如果事情开始变得太复杂，重构并简化它。通过遵循/使用模式、约定来保持一致；熟悉是保持一致性的关键。但是，也不要老是重复自己。

说到底，它实际上是关于维护应用程序。会不会有其他人能快速理解组织和逻辑，并能够维护它……简约是王道。这并不意味着它是如此简单，它是不可行或没有价值的。如果组织得当，即使是复杂的事情也可以很简单。然而，分解事物和引入抽象可能会有隐藏的代价(参见结束的想法)。

为了更具体地回答你的一些问题.

1. 我不确定MongoDB，但是(Spring ) GemFire没有外部映射。至少，如果实体类有多于一个构造函数，则需要@Region (在实体类上)和@Id，以及@PersistenceConstructor。为了示例。
2. 这听起来很像DTO。就我个人而言，我认为BoundContexts是一个更好、更自然的应用程序数据模型，因为域模型不应该过度地绑定到任何持久存储或外部表示(例如JSON、XML等)。应用程序域模型是应用程序的一个真实状态，它应该以一种自然的方式对概念进行建模，而不是表面上满足某种表示或持久存储(因此是映射/转换)。

不管怎么说，别把自己打得太厉害。这一切都是为了管理复杂性。尝试让自己做，并使用测试和其他反馈循环，以找到一个正确的答案，您的应用程序。你会知道的。

希望这能有所帮助。