1

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

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

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

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

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

一直在努力寻找最佳方法 - 任何回应都非常感谢。谢谢

4

1 回答 1

1

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

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

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

一些开发人员是纯粹主义者，喜欢将一切都外化。其他人喜欢将信息（元数据）靠近使用它的代码。甚至已经出现了某些模式来解决这些类型的问题...... DTO，有界上下文（参见Fowler 的 BoundedContext，它与 DDD 和微服务有很强的相关性）。

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

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

（以及其他一些......好的OOD，SoC，SOLID，设计模式等）。

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

归根结底，它实际上是关于维护应用程序。是否有其他人能够从您离开的地方快速理解组织和逻辑，并能够维护它......简单才是王道。这并不意味着它是如此简单以至于不可行或不有价值。如果组织得当，即使是复杂的事情也可以变得简单。但是，将事物分解并引入抽象可能会产生隐藏成本（请参阅结束思想）。

为了更具体地回答（几个）你的问题......

  1. 我不确定 MongoDB，但是（Spring Data）GemFire 没有外部映射。最低限度，@Region（在实体类上）并且@Id是必需的，以及@PersistenceConstructor您的实体类是否有超过 1 个构造函数。例如. _

  2. 这听起来像是 DTO 偷偷摸摸的。就个人而言，我认为 BoundContexts 是一个更好、更自然的应用程序数据模型，因为域模型不应该过度绑定到任何持久存储或外部表示（例如 JSON、XML 等）。应用程序域模型是应用程序的 1 个真实状态，它应该对以自然方式表示的概念进行建模，而不是表面上满足某些表示或持久存储（因此映射/转换）。

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

希望这可以帮助。

于 2016-05-25T07:10:02.583 回答