在不同的 spring 数据存储库中使用相同的实体 类
Using same Entity classes in different spring data repositories
我正在尝试整合一个项目，在该项目中我必须使用不同的 spring 数据存储库（gemfire、jpa、mongodb 等）来保存一些实体 classes。由于需要进入这些存储库的数据或多或少是相同的，我想知道我是否可以对所有这些存储库使用相同的实体 class 以避免我从一个对象转换为另一个对象？
我让它在 gemfire 和 jpa 上工作，但实体 class 已经开始看起来有点连线了。
@Id // spring-data-gemfire
@javax.persistence.Id // jpa
@GeneratedValue
private Long id;
到目前为止，我可以看到以下选项：
- 创建一个基于接口的独立实体（域）classes - 尝试重复使用相同的 class 看起来有点过早优化。
- 为 JPA 外部化基于 xml 的映射，不确定是否可以外部化 gemfire 和 mongodb 映射。
- 使用不同的具体实体 classes 并使用一些副本 constructor/converter 进行转换。
我一直在用头撞墙寻找最佳方法 - 非常感谢任何回应。谢谢
如果说奇怪，你的意思是你的应用程序域 objects/entity classes 开始积累许多不同但独立的（映射）注释（有些甚至在语义上相同，例如 SD Common 的 o.s.data.annotation.Id 和 JPA 的 @javax.persistence.Id) 对于将在其中保留这些实体的不同数据存储，那么我认为这是可以理解的。
注释污染只会随着实体表示数量的增加而增加。例如，考虑 JSON 映射的 Jackson 注释或 XML 的 JAXB 等。很快，您拥有的元数据就会比实际数据多，:-)
不过，更多的是偏好、方便、简单，真的。
一些开发人员是纯粹主义者，喜欢将一切外化。其他人喜欢让信息（元数据）靠近使用它的代码。甚至出现了某些模式来解决这些类型的问题……DTO、限界上下文（参见 Fowler 的 BoundedContext，它与 DDD 和微服务有很强的相关性）。
就我个人而言，在我的代码中设计和应用架构 principals/decisions 时，尤其是在引入新内容时，我会遵循以下规则：
- 简单
- 一致性
- 干燥
- 测试
- 重构
（以及其他一些...良好的 OOD、SoC、SOLID、设计模式等）。
也是按照这个顺序。如果某件事开始变得太复杂，请重构并简化它。通过 following/using 模式、约定在您所做的事情上保持一致；熟悉是保持一致性的关键之一。但是，也不要一直重复自己。
归根结底，这实际上是关于维护应用程序。从您离开的地方接手的其他人是否能够快速理解组织和逻辑，并能够维护它……简单为王。这并不意味着它是如此简单以至于不可行或没有价值。如果组织得当，即使是复杂的事情也可以变得简单。但是，将事物分解并引入抽象可能会产生隐性成本（请参阅结束语）。
为了更具体地回答您的（一些）问题...
我不确定 MongoDB，但是（Spring 数据）GemFire 没有外部映射。至少，@Region（在实体 class 上）和 @Id 是必需的，如果您的实体 class 具有超过 1 个构造函数，则还需要 @PersistenceConstructor。对于 example.
这听起来有点像 DTO。就我个人而言，我认为 BoundContexts 是一个更好、更自然的应用程序数据模型，因为域模型不应过度绑定到任何持久存储或外部表示（例如 JSON、XML 等）。应用程序域模型是应用程序的第一个真实状态，它应该对以自然方式表示的概念进行建模，而不是表面上满足某些表示或持久存储（因此 mapping/conversion）。
无论如何，尽量不要太自责。这一切都与管理复杂性有关。试着让自己去做，并使用测试和其他反馈循环来找到适合您的应用程序的答案。你会知道的。
希望这对您有所帮助。
我正在尝试整合一个项目，在该项目中我必须使用不同的 spring 数据存储库（gemfire、jpa、mongodb 等）来保存一些实体 classes。由于需要进入这些存储库的数据或多或少是相同的，我想知道我是否可以对所有这些存储库使用相同的实体 class 以避免我从一个对象转换为另一个对象？
我让它在 gemfire 和 jpa 上工作，但实体 class 已经开始看起来有点连线了。
@Id // spring-data-gemfire
@javax.persistence.Id // jpa
@GeneratedValue
private Long id;
到目前为止，我可以看到以下选项：
- 创建一个基于接口的独立实体（域）classes - 尝试重复使用相同的 class 看起来有点过早优化。
- 为 JPA 外部化基于 xml 的映射，不确定是否可以外部化 gemfire 和 mongodb 映射。
- 使用不同的具体实体 classes 并使用一些副本 constructor/converter 进行转换。
我一直在用头撞墙寻找最佳方法 - 非常感谢任何回应。谢谢
如果说奇怪，你的意思是你的应用程序域 objects/entity classes 开始积累许多不同但独立的（映射）注释（有些甚至在语义上相同，例如 SD Common 的 o.s.data.annotation.Id 和 JPA 的 @javax.persistence.Id) 对于将在其中保留这些实体的不同数据存储，那么我认为这是可以理解的。
注释污染只会随着实体表示数量的增加而增加。例如，考虑 JSON 映射的 Jackson 注释或 XML 的 JAXB 等。很快，您拥有的元数据就会比实际数据多，:-)
不过，更多的是偏好、方便、简单，真的。
一些开发人员是纯粹主义者，喜欢将一切外化。其他人喜欢让信息（元数据）靠近使用它的代码。甚至出现了某些模式来解决这些类型的问题……DTO、限界上下文（参见 Fowler 的 BoundedContext，它与 DDD 和微服务有很强的相关性）。
就我个人而言，在我的代码中设计和应用架构 principals/decisions 时，尤其是在引入新内容时，我会遵循以下规则：
- 简单
- 一致性
- 干燥
- 测试
- 重构
（以及其他一些...良好的 OOD、SoC、SOLID、设计模式等）。
也是按照这个顺序。如果某件事开始变得太复杂，请重构并简化它。通过 following/using 模式、约定在您所做的事情上保持一致；熟悉是保持一致性的关键之一。但是，也不要一直重复自己。
归根结底，这实际上是关于维护应用程序。从您离开的地方接手的其他人是否能够快速理解组织和逻辑，并能够维护它……简单为王。这并不意味着它是如此简单以至于不可行或没有价值。如果组织得当，即使是复杂的事情也可以变得简单。但是，将事物分解并引入抽象可能会产生隐性成本（请参阅结束语）。
为了更具体地回答您的（一些）问题...
我不确定 MongoDB，但是（Spring 数据）GemFire 没有外部映射。至少，
@Region（在实体 class 上）和@Id是必需的，如果您的实体 class 具有超过 1 个构造函数，则还需要@PersistenceConstructor。对于 example.这听起来有点像 DTO。就我个人而言，我认为 BoundContexts 是一个更好、更自然的应用程序数据模型，因为域模型不应过度绑定到任何持久存储或外部表示（例如 JSON、XML 等）。应用程序域模型是应用程序的第一个真实状态，它应该对以自然方式表示的概念进行建模，而不是表面上满足某些表示或持久存储（因此 mapping/conversion）。
无论如何，尽量不要太自责。这一切都与管理复杂性有关。试着让自己去做，并使用测试和其他反馈循环来找到适合您的应用程序的答案。你会知道的。
希望这对您有所帮助。