[SPRING] 저장소 패턴 - 어떻게 이해해야하며 "복잡한"엔티티와 어떻게 작동합니까?
SPRING저장소 패턴 - 어떻게 이해해야하며 "복잡한"엔티티와 어떻게 작동합니까?
저장소 패턴을 이해하는 데 어려움을 겪고 있습니다.
그 주제에 대한 많은 의견이 Repository 패턴처럼 잘되었지만 Repository와 같은 다른 것들도 새로운 Singleton이거나 DAO를 사용하지 마십시오. Repository를 사용하거나 Spring JPA Data + Hibernate + MySQL + MAVEN을 사용합니다. 리포지토리는 DAO 개체와 동일하게 보입니다.
imho 이후이 기사를 읽는 것에 지치고 있습니다. 많은 기사에 표시되는 것처럼 어려운 일이 될 수 없습니다.
나는 이것을 다음과 같이 본다. 나는 그것이 내가 원하는 것이 이것과 비슷한 것이라고 생각한다.
------------------------------------------------------------------------
| Server |
------------------------------------------------------------------------
| | | |
Client <-|-> Service Layer <-|-> Repository Layer <-|-> ORM / Database Layer |
| | | |
------------------------------------------------------------------------
서비스 레이어는 * DTOobjects를 가져 와서 리포지토리 레이어로 전달합니다. 기본적으로 엔티티를 저장하는 방법을 알고있는 "녀석"이상입니다.
예를 들어 몇 가지 도구로 구성되어 있다고 가정합니다 (이 코드는 단지 의사 코드입니다)
@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 객체를 얻는 부분입니다.
지금까지 이해 했으므로 "ToolSetDTO를 저장하는 방법을 알고있는"ToolSetRepository.save (ToolSetDTO toolSetDto) 메서드를 사용하여 ToolSetRepository를 작성할 수 있습니다. 그러나 거의 모든 튜토리얼은 * DTO 대신 Entity를 전달합니다.
여기서 귀찮은 것은 위에서 ToolSet 예제를 가져 오면 다음 단계를 수행해야한다는 것입니다.
이 모든 것은 너무 복잡해서 단순히 서비스 기능 (클라이언트 용 인터페이스)이이를 처리하도록합니다.
내가 생각한 것은 예를 들어 ToolSetRepository하지만 여기에있는 질문은
왜 내가이 문제를두고 머리를 맞출 수 없는지 모르겠다. 복잡한 것은 아니지만 스프링 데이터처럼 도움이됩니다. 나에게 방해가되는 또 다른 일은 이것이 어떻게 더 쉬운 일을하는지 실제로 보지 못했기 때문이다. 특히 나는 Hibernate를 이미 사용하고 있기 때문에 - 나는 이점을 보지 못했다. (하지만 아마도 다른 질문이다.)
그래서 ..이 질문은 길다는 것을 알고 있습니다 만, 저는 이미 며칠의 연구를했습니다. 지금 당장 작업중인 코드는 이미이 패턴을 볼 수 없기 때문에 엉망이되기 시작합니다.
나는 누군가가 나에게 저장소 패턴의 매우 간단한 예제를 구현하는 것을 넘어서는 대부분의 기사와 튜토리얼보다 더 큰 그림을 줄 수 있기를 바랍니다.
해결법
-
==============================
1.내 "저장소 인형"게시물을 읽으면 저장소의 간단한 원리를 이해할 수 있습니다. 귀하의 문제는 당신이 DTO와 함께 일하고 그 시나리오에서 실제로 DAO를 사용하는 저장소 패턴을 사용하지 않는다고 생각합니다.
내 "저장소 인형"게시물을 읽으면 저장소의 간단한 원리를 이해할 수 있습니다. 귀하의 문제는 당신이 DTO와 함께 일하고 그 시나리오에서 실제로 DAO를 사용하는 저장소 패턴을 사용하지 않는다고 생각합니다.
저장소와 DAO의 주요 차이점은 저장소가 호출 계층에서 이해하는 개체 만 반환한다는 것입니다. 대부분의 경우 리포지토리는 비즈니스 계층에서 사용되므로 비즈니스 개체를 반환합니다. DAO는 전체 비즈니스 객체 일 수도 그렇지 않을 수도있는 데이터를 반환합니다. 즉, 데이터는 유효한 비즈니스 개념이 아닙니다.
비즈니스 객체가 단지 데이터 구조 일 경우 모델링 문제, 즉 잘못된 디자인이라는 힌트 일 수 있습니다. 리파지토리는 '리치 (rich)'또는 적어도 적절하게 캡슐화 된 객체를 사용하는 것이 더 적합합니다. 데이터 구조를로드 / 저장하는 중이라면 orm 만 있으면 충분할 것입니다.
일관성을 유지하기 위해 다른 오브젝트 (집계)에서 작성된 비즈니스 오브젝트를 처리하고 해당 오브젝트가 모든 파트를 필요로하는 경우 (집계 루트) 저장소 패턴이 모든 지속성 세부 사항을 추상화 할 것이므로 최상의 솔루션입니다 . 앱은 '제품'을 요청할 것이고 리포지토리는 개체를 복원하는 데 필요한 테이블 또는 쿼리 수에 관계없이 전체적으로이를 반환합니다.
코드 샘플을 기반으로 '실제'비즈니스 오브젝트가 없습니다. 당신은 Hibernate에 의해 사용 된 데이터 구조를 가지고있다. 비즈니스 개체는 비즈니스 개념 및 사용 사례를 기반으로 설계되었습니다. 저장소는 BL이 그 객체가 어떻게 지속되는지를 신경 쓰지 않게 할 수있다. 어떤면에서 저장소는 유지 될 객체와 모델 사이의 '변환기 / 매퍼'역할을합니다. 기본적으로 repo는 객체를 지속성 데이터에 필요한만큼 '줄입니다'.
비즈니스 오브젝트는 ORM 엔티티가 아닙니다. 기술적 인 관점에서 볼 수 있지만, 디자인 포브 (pov)에서 비즈니스 모델은 비즈니스 모델로, 다른 모델은 지속성을 모델링합니다. 대부분의 경우 이들은 서로 호환되지 않습니다.
가장 큰 실수는 저장소 요구와 사고 방식에 따라 비즈니스 개체를 디자인하는 것입니다. 그리고 많은 devs가 믿는 것과는 달리 ORM 목적은 비즈니스 객체를 유지하는 것이 아닙니다. 그 목적은 rdbms 상단에 'oop'데이터베이스를 시뮬레이트하는 것입니다. ORM 매핑은 db 객체와 테이블 사이에 있으며 app 객체 (비즈니스 객체를 다루는 경우는 적음)와 테이블 사이가 아닙니다.
from https://stackoverflow.com/questions/31305199/repository-pattern-how-to-understand-it-and-how-does-it-work-with-complex-en by cc-by-sa and MIT license