我很难理解存储库模式。
关于该主题有很多意见,例如在Repository模式中做得正确,但其他信息,例如Repository是新的Singleton或再次,例如在不要使用DAO中使用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
从上面举我的例子,我将必须执行以下步骤:
toolSetDto
并检查是否null
tool*Dto
拥有者toolSetDto
DTO
,Entity
否则创建一个新的数据库条目toolDescriptionDto
并将其转换/保存到数据库或创建一个新条目ToolSet
完上述实例(实体)并将其设置为持久保存在数据库中之后所有这些都太复杂了,以至于不能简单地让服务功能(客户端的接口)来处理。
我当时想的是创建一个,ToolSetRepository
但是这里的问题是
ToolSet
实体对象还是使用DTO
对象?*Repository
允许使用其他存储库对象?就像当我要救ToolSet
,但我必须存储Tool
和ToolDescription
第一-我会用ToolRepository
和ToolDescriptionRepository
里面ToolSetRepository
?*Repository
由于依赖关系的原因,它只是“感觉不到”将依赖关系添加到其他类。我不知道为什么我无法解决这个问题。这听起来并不认为复杂,但还是有帮助有像Spring Data
。另一件事困扰着我,因为我真的不知道这如何使事情变得容易。特别是因为我已经在使用Hibernate-我看不到好处(但这可能是另一个问题)。
所以..我知道这是一个很长的问题,但我已经对其进行了几天的研究。我现在正在使用的现有代码已经变得一团糟,因为我无法看清这种模式。
我希望有人能给我比大多数文章和教程更大的印象,而这些文章和教程只能实现一个非常非常简单的存储库模式示例。
您可以阅读我的“傻瓜存储库” 帖子,以了解存储库的简单原理。我认为您的问题是您正在使用DTO,在这种情况下,您实际上并没有使用存储库模式,而是在使用DAO。
存储库和dao之间的主要区别在于,存储库仅返回调用层可以理解的对象。大多数时候,存储库被业务层使用,因此它返回业务对象。dao返回的数据可能是也可能不是整个业务对象,即该数据不是有效的业务概念。
如果您的业务对象只是数据结构,则可能暗示您存在建模问题,即设计不良。存储库对于“丰富”或至少正确封装的对象更有意义。如果您只是加载/保存数据结构,则可能不需要存储库就可以了。
如果要处理由其他对象(聚合)组成的业务对象,并且该对象需要其所有部分才能保持一致(聚合根),那么存储库模式是最佳解决方案,因为它将抽象所有持久性详细信息。您的应用将只要求一个“产品”,并且存储库将整体上将其返回,而不管要恢复该对象需要多少张表或查询。
根据您的代码示例,您没有“真实的”业务对象。您具有Hibernate使用的数据结构。根据业务概念和用例设计业务对象。该存储库使BL不必关心该对象的持久化方式。在某种程度上,存储库充当对象和将要持久化的模型之间的“转换器/映射器”。基本上,存储库将对象“还原”为持久性数据所需。
业务对象不是 ORM实体,它可能是从技术角度来看的,但是从设计角度来看,一个模型业务对象,其他模型持久性对象。在许多情况下,这些不是直接兼容的。
最大的错误是根据存储需求和思维方式设计业务对象。与许多开发人员所认为的相反,ORM的目的不是持久化业务对象。其目的是在rdbms之上模拟“ oop”数据库。ORM映射在您的数据库对象和表之间,而不是在应用程序对象(处理业务对象时更少)和表之间。
本文收集自互联网,转载请注明来源。
如有侵权,请联系 [email protected] 删除。
我来说两句