存储库模式-如何理解它以及它如何与“复杂”实体一起工作？

Question

我很难理解存储库模式。

关于该主题有很多意见，例如在Repository模式中做得正确，但其他信息，例如Repository是新的Singleton或再次，例如在Do n’t use DAO use
Repository中，
或者只是以某种方式使用Spring JPA Data + Hibernate + MySQL +
MAVEN
存储库似乎与DAO对象相同。

我厌倦了阅读这些东西，因为恕我直言，这在很多文章中都不是一件难事。

我看到的是这样的：看来我想要的是这样的：

         ------------------------------------------------------------------------
         |                            Server                                    |
         ------------------------------------------------------------------------
         |                    |                        |                        |
Client <-|-> Service Layer  <-|->  Repository Layer  <-|-> ORM / Database Layer |
         |                    |                        |                        |  
         ------------------------------------------------------------------------

在Service Layer需要*DTO的对象，并将这些的Repository Layer，基本上不外乎谁知道“的家伙” 怎么
一个实体可以存储。

例如，假设您具有一些工具的组合（ 请注意，这只是伪代码 ）

@Entity
class ToolSet {
  @Id
  public Long id;
  @OneToOne
  public Tool tool1;
  @OneToOne
  public Tool tool2;
}

@Entity
class Tool {
  @Id
  public Long id;
  @OneToMany
  public ToolDescription toolDescription;
}

@Entity
class ToolDescription {
  @Id
  public Long id;
  @NotNull
  @OneToOne
  public Language language

  public String name;
  public String details;
}

我没有得到的是ToolSetDTO从客户端获得对象的部分。

据到目前为止的理解，我可以ToolSetRepository用一种ToolSetRepository.save(ToolSetDTO toolSetDto)“ 知道如何存储 ” a
的方法来写一个ToolSetDTO。但是几乎每个教程都没有通过，*DTO而是通过了Entity。

让我困扰的是，如果您ToolSet从上面举我的例子，我将必须执行以下步骤：

1. 采取toolSetDto并检查是否null

2. 对于每个tool*Dto拥有者toolSetDto
   a）如果具有有效的id，则从转换为DTO，Entity否则创建一个新的数据库条目
   b）toolDescriptionDto并将其转换/保存到数据库或创建一个新条目

3. 在检查ToolSet完上述实例（实体）并将其设置为持久保存在数据库中之后

所有这些都太复杂了，以至于不能简单地让服务功能（客户端的接口）来处理这个问题。

我当时在想创建一个，ToolSetRepository但是这里的问题是

• 它采用ToolSet实体对象还是使用DTO对象？
• 无论如何：*Repository允许 使用 其他存储库对象吗？就像当我要救ToolSet，但我必须存储Tool和ToolDescription第一-我会用ToolRepository和ToolDescriptionRepository里面ToolSetRepository？
  如果是这样：为什么它不破坏存储库模式？如果此模式基本上是服务和我的ORM框架之间的一层，则*Repository由于依赖关系的原因，它只是“感觉不到”将依赖关系添加到其他类中。

我不知道为什么我无法解决这个问题。这听起来并不 认为 复杂，但还是有帮助有像Spring Data。另一件事困扰着我，因为我真的不知道这如何使
事情 变得容易。特别是因为我已经在使用Hibernate-我看不到好处（但这可能是另一个问题）。

所以..我知道这是一个很长的问题，但是我已经花了几天的研究时间。我现在正在使用的现有代码已经变得一团糟，因为我无法看清这种模式。

我希望有人能给我比大多数文章和教程更大的印象，而大多数文章和教程都只能实现一个非常非常简单的存储库模式示例。

Answer 1

您可以阅读我的“傻瓜存储库” 帖子，以了解存储库的简单 原理
。我认为您的问题是您正在使用DTO，在这种情况下，您实际上并没有使用存储库模式，而是在使用DAO。

存储库和dao之间的主要区别在于，存储库仅返回 调用层可以理解的
对象。大多数时候，存储库被业务层使用，因此它返回业务对象。dao返回的数据可能是也可能不是整个业务对象，即该数据不是有效的业务概念。

如果您的业务对象只是数据结构，则可能暗示您存在建模问题，即设计不良。存储库对于“丰富”或至少正确封装的对象更有意义。如果仅加载/保存数据结构，则可能不需要存储库就可以了。

如果要处理由其他对象（聚合）组成的业务对象，并且该对象需要其所有部分才能 保持一致
（聚合根），那么存储库模式是最佳解决方案，因为它将抽象所有持久性详细信息。您的应用将只要求一个“产品”，并且存储库将整体上将其返回，而不管要恢复该对象需要多少张表或查询。

根据您的代码示例，您没有“真实的”业务对象。您具有Hibernate使用的数据结构。根据业务概念和用例设计业务对象。该存储库使BL不必关心该对象的持久化方式。在某种程度上，存储库充当对象和将要持久化的模型之间的“转换器/映射器”。基本上，存储库将对象“还原”为持久性数据所需。

业务对象 不是 ORM实体，它 可能
是从技术角度来看的，但从设计角度来看，一个模型业务对象，其他模型持久性对象。在许多情况下，这些不是直接兼容的。

最大的错误是根据存储需求和思维方式设计业务对象。与许多开发人员所认为的相反，ORM的目的不是持久化业务对象。其目的是在rdbms之上模拟“
oop”数据库​​。ORM映射是在数据库对象和表之间，而不是在应用程序对象（处理业务对象时更少）和表之间。