가끔은 Entity class 를 만드는 이유가 궁굼해 집니다.

emptynote의 이미지

가끔은 Entity class 를 만드는 이유가 궁굼해 집니다.

EJB 모릅니다. DomainDrivenDesign 도 모릅니다.

참고 url : http://aeternum.egloos.com/1115939

VO, DTD를 찾다보니 DDD라는 용어도 나와서 무언가 해서 찾아보았습니다.

글을 읽다 보니 Entity를 두고 그를 운용할려는 것을 보면 이해가 안갑니다.

어짜피 DB table를 ER-Diagram 기반으로 설계를 하면,

프로그램안에 Entity를 중복해서 두어 운용해야 하는가? 라는 의문이 드네요.

제가 많이 삐뚫어져 있으니깐 그리고 많이 부족해서 일겁니다.

그래서 왜 저런 헛발질을 해야 하는지 이해가 안갈뿐입니다.

익명 사용자의 이미지

뭐 현업에서 사실상은 관계형 DB를 사용하는 것이 거의 대부분이겠지만...
혹시라도 persistence를 DB 가 아닌 다른 것을 사용하려면 어떻게 할지요?
예를 들어 어떤 웹사이트에서 제공하는 Open API 를 통해 얻은 XML 데이터나 JSON 데이터를 entity 로 사용해야한다면요?
관계형 DB를 직접 사용하더라도 어떤 경우에는 DB를 스스로 디자인하지 못하고, 남이 제공해주는대로만 사용해야하는 경우도 있습니다.
그러면 여러모로 입맛에 맞지 않을 가능성이 크지요.
구체적인 저장 방법으로부터 한 단계 추상화를 하는 것이 여러모로 좋습니다.
Entity class 는 그런 용도라고 생각하시면 됩니다. 중복이라기보다는 추상화입니다.

emptynote의 이미지

남이 제공해주는대로만 사용해야하는 경우

한단계 추상화가 좋다는 말씀은 공감이 가네요.

그런 이유에 대한 방법론이었군요.

좋은 답변 감사합니다.

kwon37xi의 이미지

Entity를 만드는게 이해가 안되시는 것인지요?
아니면 Entity가 이미 있는데 VO,DTO(DTD라고 쓰셨는데 DTO를 뜻하신거인가요? Data Transfer Object)를 왜 만들어야 하냐라는 질문이신건가요?

과거에 EJB를 쓰던 시절에는 DTO/VO를 만들어 쓰는 패턴을 많이 썼습니다만 요즘에는 Hibernate/JPA 등의 ORM을 쓰면서 VO/DTO를 만들어 쓰는 경우는 거의 없습니다. EJB 3가 나오면서 JPA가 도입되어서 EJB를 쓸 때도 마찬가지로 DTO/VO를 거의 안만들지 않을까 싶습니다.

과거 EJB의 구조적인 문제 때문에 DTO/VO를 만들어 썼던거 같은데, 사실 EJB를 써본적이 없어서 제가 설명은 못드리겠네요.

아무튼, 지금은 시대가 변하여 ORM을 사용하면서 DTO/VO를 만드는 경우는 거의 없습니다. 그냥 ORM의 Entity 클래스 하나만 두고 씁니다. 어쩌다가 DB Entity 구조와 너무도 다른 데이터 조합결과 등이 필요할 때(보통 통계?) 그럴 때만 ORM과 연동 없이 데이터만 주고 받기 위한 VO를 만들기도 하긴 합니다만... 이건 Entity의 구조를 그대로 본따 만드는게 아니기 때문에 논외가 되겠죠.

emptynote의 이미지

Entity가 이미 table에 있을때를 말합니다.

오해 없으시기 바랍니다.

unsouled의 이미지

글을 잘 읽으시면 알겠지만 위의 DDD 에서 말하는 Value Object 는 일반적으로 통용되는 의미의 VO(일반적으로 Java Beans 의 형태를 가진) 와 다른 개념입니다.

DDD 는 중복되는 Entity 클래스를 만드는 게 아니라 그런 모델을 anemic domain model 이라고 비판하며 rich domain model 과 함께 나온 방법입니다.

자신이 이해하지 못한다고 헛발질로 매도하시는 건 곤란합니다.

emptynote의 이미지

무식한거 티 안내면 아무것도 모르고 평생 지내야해서리 콜록~ 콜록~