我试图整理一个项目，我必须使用不同的Spring数据存储库（gemfire，jpa，mongodb等）来持久保存一些实体类。由于数据或多或少与需要进入这些存储库的数据相同，我想知道我是否可以使用相同的实体类来保存我从一个对象转换到另一个对象？
我让它为gemfire和jpa工作但是实体类已经开始看起来有点连线了。
@Id // spring-data-gemfire
@javax.persistence.Id // jpa
@GeneratedValue
private Long id;
到目前为止，我可以看到以下选项：
一直撞到墙上找到最好的方法 - 任何回应都非常感谢。感谢
答案 0 :(得分：1)
如果很奇怪，你的意思是你的应用程序域对象/实体类开始积累许多不同的，但是单独的（映射）注释（在某种程度上语义相同，例如SD Common o.s.data.annotation.Id和JPA {{1}对于将保留这些实体的不同数据存储，我认为这是可以理解的。
随着实体表示数量的增加，注释污染也会增加。例如，想想杰克逊的JSON映射注释或JAXB for XML等等。很快，你有更多的元数据然后是实际的数据，： - ）
然而，这更多的是偏好，方便，简单，真的。
有些开发人员是纯粹主义者，他们喜欢外化一切。其他人喜欢使用它来保持信息（元数据）接近代码。甚至出现了某些模式来解决这些类型的问题...... DTO，有界上下文（参见 Fowler的 BoundedContext，它与DDD和微服务有很强的相关性。）
就个人而言，在我的代码中设计和应用架构主体/决策时，我会使用以下规则，尤其是在引入新内容时：
（以及其他一些......好的OOD，SoC，SOLID，设计模式等）。
也按顺序。如果某些东西开始变得太复杂，重构并简化它。通过遵循/使用模式，约定来保持一致;熟悉是一致性的关键。但是，不要一直重复自己。
在一天结束时，它实际上是关于维护应用程序。从你离开的地方回来的其他人是否能够快速理解组织和逻辑，并能够维持它......简单就是王道。这并不意味着它如此简单，它不可行或有价值。如果组织得当，即使复杂的事情也很简单。但是，将事情分开并引入抽象可能会产生隐藏成本（见结束思路）。
更具体地回答（一些）你的问题......
我不确定MongoDB，但是（Spring Data）GemFire没有外部映射。最低限度，如果您的实体类具有多个构造函数，则需要@javax.persistence.Id（在实体类上）和@Region以及@Id。对于example。
这听起来像DTOs。就个人而言，我认为BoundContexts是应用程序数据的更好，更自然的模型，因为域模型不应过度依赖任何持久存储或外部表示（例如JSON，XML等）。应用程序域模型是应用程序的1个真实状态，它应该以自然的方式对概念进行建模，而不是表面上满足某些表示或持久存储（因此映射/转换）。
无论如何，尽量不要打得太多。一切都与管理复杂性有关。尽量让自己做，并使用测试和其他反馈循环来找到适合您的应用程序的答案。你会知道的。
希望这有帮助。