存储库模式——如何理解它，以及它如何与“复杂”实体协同工作？

Question

我很难理解存储库模式。

关于这个主题有很多意见，比如在存储库模式中做得对，但也有其他东西，比如存储库是新的单例，或者像在不要使用DAO使用存储库或只是使用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。保存（ToolSetDTO ToolSetDTO）它“知道如何存储”一个ToolSetDTO。但几乎所有教程都不是通过*DTO，而是通过实体。

这里让我感到困扰的是，如果你以我上面的工具集为例，我必须执行以下步骤：

1. 将工具集设置为并检查是否为null
2. 对于toolSetDto
   a）拥有的每个tool*Dto如果有一个有效的id，则从Dto转换为实体否则创建一个新的数据库条目
   b）toolsdescriptiondto并将其转换/保存到数据库或创建一个新条目
3. 在检查完以上内容后，实例化工具集（实体），并将其设置为在数据库中持久化

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

我想的是创建一个例如ToolSetRepository，但这里的问题是

• 它是采用ToolSet实体对象还是使用DTO对象？
• 在任何情况下：*Repository是否允许使用其他存储库对象？就像当我想保存ToolSet但我必须首先存储Tool和ToolDescription-我会在ToolRepository和ToolDescriptionRepository内部使用ToolSetRepository吗？
  如果是这样：为什么它不破坏存储库模式？如果这个模式基本上是服务和我的ORM框架之间的一层，它只是不“感觉正确”添加依赖到其他*Repository类由于依赖原因。

我不知道为什么我不能理解这件事。听起来没那么复杂，但仍然有帮助，比如Spring Data。另一件事困扰着我，因为我真的不明白这如何让事情变得更容易。尤其是因为我已经在使用Hibernate了——我看不出它有什么好处（但这可能是另一个问题）。

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

我希望有人能给我一个比大多数文章和教程更大的图景，这些文章和教程除了实现一个非常非常简单的存储库模式示例之外。




Answer 1

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

存储库和dao之间的主要区别在于，存储库只返回调用层能够理解的对象。大多数情况下，存储库由业务层使用，因此，它会返回业务对象。dao返回的数据可能是也可能不是整个业务对象，即数据不是有效的业务概念。

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

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

根据您的代码示例，您没有“真实”的业务对象。您有Hibernate使用的数据结构。业务对象是基于业务概念和用例设计的。存储库使BL可以不关心该对象是如何持久化的。在某种程度上，存储库充当对象和将被持久化的模型之间的“转换器/映射器”。基本上，repo将对象“减少”到持久化数据所需的大小。

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

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