좌충우돌 ORM 개발기 | Devon 2012

좌충우돌 ORM개발기Daum 김영한

목차• 프로젝트 구조와 모순

• Why ORM?

• DEMO 프로젝트

• ORM 적용시 고민할 2가지 구조

• Domain Model Everywhere

• DTO, Pure Domain Model

프로젝트 구조와 모순

화면 중심 프로젝트

• 화면 중심으로 프로젝트 구조를 구성

• View 단위로 개발자 투입

• Service, Dao, Entity를 각자 만들어 써야함, 공유하는 것은 허용하지 않음

회원관리 화면 Package controller (MemberController) service (MemberService) dao (MemberDao) entity (Member)

상품 관리 화면 Package controller (ProductController) service (ProductService) dao (ProductDao) entity (Product)

회원관리화면 상품관리화면 주문관리화면

A개발자 B개발자 C개발자

회원관리화면

상품관리화면

주문관리화면

A개발자

B개발자

C개발자

MemberController MemberService MemberDao MemberEntity

ProductController ProductService ProductDao ProductEntity

OrderController OrderService OrderDao OrderEntity

회원관리화면

상품관리화면

주문관리화면

A개발자

B개발자

C개발자

MemberController MemberService MemberDao MemberEntity

MemberDao MemberEntity

MemberDao MemberEntity

ProductController ProductService ProductDao ProductEntity

OrderController OrderService OrderDao OrderEntity

ProductDao ProductEntity

중복!!!

• 프로젝트가 계속 진행되면...

• 같거나 유사한 Query가 무수히 나타남

• 회원정보 조회의 경우 11번의 거의 동일한 쿼리 발견

• 수정이 아주 어려움

• 월화수목금금금... --;

화면중심 프로젝트 구조는수 많은 중복을 만든다.

일반적인 프로젝트

• 데이터와 비지니스 로직을 중심으로프로젝트를 설계한다.

회원관리, 상품관리controller - MemberController - ProductControllerservice - MemberService - ProductServicedao - MemberDao - ProductDaoentity - Member - Product

MemberController

ProductController

MemberService

ProductService

MemberDao

ProductDao

Member Product

실전에선멀티 프로젝트

FRONT

ADMIN

BATCH

A,B개발자

C,D개발자

E개발자

ADMIN

BATCH

FRONTMemberDao

MemberEntity

MemberDao

MemberEntity

MemberDao

MemberEntity

중복!!!

CORE

멀티 모듈 프로젝트

MemberDao

MemberEntity

MemberDao

MemberEntity

MemberDao

MemberEntity

FRONT ADMIN BATCH

사용되는 Member의 정보

FRONT

MemberEntity

회원이름 나이 성별

MemberEntity

회원이름 나이 성별

주민번호

회원번호

전화번호


ADMIN


BATCH

MemberEntity

회원이름 성별

주민번호

회원번호

데이터 불일치

• CORE로 통합시 또 다른 문제 발생

• SQL의 Projection은 각 모듈의 비즈니스 로직과 View에 최적화

• findFrontMemberfindAdminMember ...???

데이터 불일치 해결 방안

• Row단위로 전체 조회

• 특별한 경우만 최적화

• 파레토법칙(20/80법칙)

하지만...

Join의 경우

회원 회원관리직원멤버십카드

class Member { Card card; Manager manager;

Card getCard(); Manager getManager();}


Join의 경우


Front

SQL : Member Join CardCode : member.getCard()

member.gerManager() ???

Join의 경우

NullPointException!!!NullPointException!!!NullPointException!!!NullPointException!!!

Join의 경우


Admin

SQL : Member Join ManagerCode : member.getManager()

member.getCard() ???

Join의 경우

NullPointException!!!NullPointException!!!NullPointException!!!NullPointException!!!

Join의 경우


Batch

SQL : Member Join Manager Join CardCode : member.getManager(), member.getCard()

불필요한 조인, 성능 낭비

Join의 경우


Front

Admin

Batch

Join의 경우

• Entity가 실행한 SQL에 데이터를 의존

• Entity에 구멍이남

• 결국 비즈니스 로직이 SQL에 의존

• 모든 데이터를 메모리에 올리는 것은 현실적이지 않음

프로젝트 구조와 모순의결론

• Entity가 SQL에 의존

• 구멍난 Entity

• 신뢰할 수 없는 Entity

• 진정한 의미의 계층 분할이 어려움

Why ORM?

ORM을 사용하는 이유• Projection 문제

• Join 관련 데이터 연결 문제

• Entity 데이터에 대한 신뢰

• 제대로 된 프로젝트 구조

• CRUD SQL좀 알아서 해줬으면

• 진정한 객체 지향 개발 가능

• 도메인 주도 개발 가능

SQL을 사용해야 하는 이유

• 우리가 사용 중인 DB는 RDB다!!!

• 통계 데이터

• 아주 복잡한 View

ORM을 사용하는진짜 이유!

컴퓨터가 할 수 있는 일을 더이상 사람이 하지 말자 나는 SQL MAPPER가 아니다!

JDBC xBatis

ORM

여기서 잠깐!

ORM에 관한 오해Q : OBJECT DB같은 것 아닌가요? 이미 망한 기술로 알고 있는데요?

A : OBJECT DB가 아닙니다. ORM은 RDB를 사용해야 한다는 것을 인정하고 RDB를 객체지향 적으로 사용 할 수 있도록 중간 역할을 하기위해 만들어 졌습니다. 그래서 이름도 Object-Relational-Mapping 입니다.

ORM에 관한 오해Q : 성능이 느리다.

A : 지금 JAVA가 느리다고 하는 것과 비슷합니다. 잘 알고 쓰게되면 SQL보다 최적화 하기가 쉽습니다. 가장 중요한 것은 파레토의 법칙입니다. 때로는 순수SQL을 써서 최적화 해야 하는 경우도 있습니다.

예) 여러 Table에 insert시 Hibernate는 한번에 batch insert를 시도함, 1차 케시를 통해 한번 조회한 데이터 조회시 메모리에서 읽어옴

ORM에 관한 오해

Q : ORM을 사용하면 SQL을 못쓴다.

A : 이거야 말로... ORM도 결국은 SQL을 작성해서 DB 와 통신하게 됩니다. 필요하면 언제든지 직접 SQL을 작성 할 수 있습니다. 물론 myBatis 같은 것과 함께 사용하는 것도 가능합니다.


Q : SQL을 몰라도 되나요?

A : 오히려 SQL에 관해서 잘 알아야 합니다. 최종적으로는 SQL이 생성되니까요.

ORM에 관한 오해Q : 공부할 내용이 많으면 어쩌지...

A : 이건 인정합니다. --; 중요한 것은 ORM의 철학을 이해하는 것입니다. 하지만 이것저것 다 떠나서 단순하게 사용하더라도 충분히 유용합니다. 궁극적으로는 ORM을 활용해서 제대로 된 DDD(도메인 주도 개발)를 하는 것이 목표라고 생각합니다.


Q : 모두 iBatis, myBatis만 사용하는데요?

A : 진실은?

2012년 8월 한국 구글 검색

myBatis31%

iBatis49%

Hibernate12%

JPA8%

myBatis iBatis Hibernate JPA

2012년 8월 인도 구글 검색iBatis3%

Hibernate86%

JPA11%


2012년 8월 미국 구글 검색myBatis

2%iBatis4%

Hibernate78%

JPA16%


2012년 8월 전세계 구글 검색myBatis

3%iBatis3%

Hibernate61%

JPA33%


ORM을 사용하고 싶은데 어떻게 시작하나요?

• 공부해야 합니다!

• JPA?

• Hibernate?

• SpringDataJPA

• QueryDSL

DEMO 프로젝트

• 사용된 기술 : JPA2, Hibernate, Spring-Data-JPA, QueryDSL, Spring, Maven

• source : https://github.com/holyeye/devon2012

멤버십 프로젝트

https://github.com/holyeye/devon2012




회원카드

회원카드

카드적립 포인트

1 : N N : 1

1:

N

적립률

도메인 모델

Create

도메인 객체@Getter @Setter@Entitypublic class Member extends BaseEntity<Long>{

private String name; private int age; @OneToMany(mappedBy="member") List<MemberCard> memberCards = new ArrayList<MemberCard>();

public void addMemberCard(MemberCard memberCard) { memberCards.add(memberCard); }}

@Getter @Setter@Entitypublic class Card extends BaseEntity<Long>{

private String name; private int rate; //적립률 //create public CardPoint createCardPoint(int money) { return new CardPoint(name,money,rate); }}

@Getter @Entitypublic class MemberCard extends BaseEntity<Long>{

@OneToMany(cascade=CascadeType.PERSIST) @JoinColumn(name="memberCard_id") private List<CardPoint> cardPoints = new ArrayList<CardPoint>(); @ManyToOne private Member member; @ManyToOne private Card card; //BIZ

public void payMoney(int money) { CardPoint createCardPoint = card.createCardPoint(money); addCardPoint(createCardPoint); } //VIEW Logic public int getTotalPoint() { int totalPoint = 0; for (CardPoint cardPoint : cardPoints) { totalPoint += cardPoint.getPoint(); } return totalPoint; }}

회원 조회, QueryDSL

@RequestMapping("member/home") public String home(MemberCond cond, Model model) {

//QUERY DSL QMember qMember = QMember.member; BooleanExpression containsName = qMember.name.contains(cond.getName()); BooleanExpression gtAge = qMember.age.gt(cond.getAge()); model.addAttribute("members",memberRepository.findAll(containsName.and(gtAge)));

return "member/home"; } public interface MemberRepository extends

JpaRepository<Member, Long>, QueryDslPredicateExecutor<Member>{

}

select * from Member memberwhere (member.name like '%서%') and member.age > 26

회원 등록, SpringDataJPA

@RequestMapping("member/saveMember") public String saveMenu(Member member) {

memberRepository.save(member); return "redirect:/member/home"; }

public interface MemberRepository extendsJpaRepository<Member, Long>, QueryDslPredicateExecutor<Member>{

}

`

회원 수정, Web Binding

/member/memberUpdateForm?id=

@RequestMapping("member/memberUpdateForm") public String memberUpdateForm(@RequestParam("id") Member member, Model model) {

model.addAttribute("member", member); return "member/memberSaveForm"; }

1

Member

회원카드 결제하기 = ORM 저장

10000만원 결제, 10% 적립

회원카드

카드적립 포인트

Domain Driven Design 살짝 맛보기

Aggregate ROOT

Aggregate(집합)

MemberCardRepository

회원카드 결제하기 = ORM 저장 @RequestMapping("memberCard/payMoney") public String payMoney( @RequestParam("memberCardId") MemberCard memberCard, @RequestParam("money") int money) { memberCardService.payMoney(memberCard, money); return "redirect:/memberCard/home"; } @Service

@Transactionalpublic class MemberCardService { public void payMoney(MemberCard memberCard, int money) { memberCard.payMoney(money); }} public class MemberCard {

@OneToMany(cascade=CascadeType.PERSIST) @JoinColumn(name="memberCard_id") private List<CardPoint> cardPoints = new ArrayList<CardPoint>(); public void payMoney(int money) { CardPoint createCardPoint = card.createCardPoint(money); cardPoints.add(createCardPoint); }

public class Card{

private String name; private int rate; public CardPoint createCardPoint(int money) { return new CardPoint(name,money,rate); }}

Auto SAVE

`

`

Spring-Data-JPA 소개• interface로 Repository 자동 생성

(CRUD, 조회)

• simple queriesex) findByName(String name) select * from member where name={name}

• pagination

• Web Binding

• Specifications, QueryDSL지원

QueryDSL 소개

• type-safe JPA queries - 단단하다

• 단순하고 쉽다.

• 지속적인 버전업

• Spring Data에서도 사용가능

ORM 적용시 고민할 2가지 구조

• ORM을 적용하는 방법은 크게 2가지

• Domain Model Everywhere

• Pure Domain Model

Domain Model Everywhere vs

Pure Domain Model

Domain Model Everywhere

Controller Service Repository

Entity+Getter,Setter

+BizLogic+ViewLogic

King

View

• Domain Model을 모든 Layer에서 적극 사용하자.

• OSIV(Open Session In View) 사용

• Getter, Setter 사용

• DTO는 중복 악마다!


• 장점• 개발하기에 빠르고 편리함

• 단점• 복잡한 View 표현 힘듬

• Domain Model의 Getter, Setter를 노출, View로직 추가

• Domain Model의 순수성이 떨어짐

• XML, JSON, 외부와의 통신API 위험 = 도메인 모델은 생각보다 자주 변함




Entity+Getter,Setter

+BizLogic+ViewLogic

King

View

Pure Domain Model


Entity+BizLogic

View

DTO+Getter,Setter

+ViewLogic

Converter

• 도메인모델에 Getter, Setter는 지옥행

• 도메인모델에 View로직은 지옥행

• OSIV(Open Session In View)는 지옥행

• 도메인모델을 객체답게 만들어라!

Pure Domain Model

Pure Domain Model

Robert C. Martin(uncle bob) 필독서!!!

OOP캡슐화, 다형성내부 변수를 노출하지 않음

일반적으로 Getter, Setter 를 이용해서 내부 변수를 모두 노출사이비 캡슐화

Pure Domain Model

객체(Domain Model)

자료 구조(DTO)

Pure Domain Model


+

자료 구조(DTO)

Pure Domain Model


자료 구조(DTO)

+ =

잡종

Pure Domain Model

잡종이런 잡종 구조는 새로운 함수는 물론이고 새로운 자료 구조도 추가하기 어렵다.

양쪽 세상에서 단점만 모아 놓은 구조다. 그러므로 잡종 구조는 되도록 피하는 편이

좋다.- Clean Code, Chapter 6 객체와 자료구조 -

• 그럼 어떻게 개발하라고요--;

Pure Domain Model

• CQRS Pattern, DTO 활용

• 도메인 모델 = 비즈니스 로직

• View는 DTO만 사용

Pure Domain Model

CQRS

• Command Query Responsibility Segregation

• 등록,수정,삭제 같은 명령어와조회용 쿼리를 분리!

CQRS

• QueryService

• CommandService

Command Query

변경

검증

비즈니스 로직수정

가끔 변경됨 자주 변경됨

O X

O X

• 장점

• 순수한 Domain Model

• 단점

• DTO를 만드는 것은 귀찮다, 성가시다. 괴롭다.

• DTO는 또다른 중복이다.

• DTO와 Domain Model의 Convert를 고민해야 한다.

Pure Domain Model

결론

그럼 어떻게 해요?

여기서 부턴 지극히 주관적입니다.

순수한 객체No Getter, Setter!Law of Demeter

SRP, DIP, OCP, ISP, LSP

도메인 객체는순수해야 한다!


객체의 순수성을 파괴하는 사악한 방법!

Getter, Setter 필수Entity = 자료구조+객체

이라고 믿고 살았습니다...직접 개발해 보기 전까진...

진짜 ORM 개발을 해보신 분은 아시겠지만...

도메인 모델만으로모든 View를 표현하는 것은

한계가 있습니다.

항상 DTO를 만드는 것은실용적이지 않습니다.

항상 DTO를 만들면 도메인 객체에 Getter, Setter만들 필요가 없고, VIEW로직 필요 없고순도 100% 도메인 객체를 유지가능 합니다, 하지만 DTO를 아주 많이 만들어야 하고 또한

ENTITY를 DTO로 바꾸고 DTO를 ENTITY로 변경해야 하는 컨버팅 필요. 관리 포인트가 3가지로 늘어남. 아주 괴로움. 때로는 배보다 배꼽이 큽니다!

결론

Domain Model Everywhere 로 시작Domain Model로 처리하기 힘든복잡하고 특별한 경우에는CQRS, DTO를 사용

Domain Model Everywhere는 진짜 실용적이고 개발하기 편합니다.DTO가 필수인 경우 = ex) 복잡한 View, [json, xml, 외부노출 API]

CQRS, DTO, Domain Model Everywhere는 프로젝트 규모와 상황을 판단해서 적용해야 합니다.지극히 주관적인 생각으로는 프로젝트 시작시 Domain Model Everywhere로 시작하고 CQRS, DTO는 필요성을 느끼게

되면 추가해 가는 것이 좋다고 생각합니다. 순도 100%는 아니지만 80%는 지킬 수 있다고 생각합니다.

• Domain Driven Design

• Pure Domain Model 을 유지하며 실용적으로 개발하는 방법

• DTO를 생성하는 방법, 활용법

• ex) http://modelmapper.org/

• ex) Builder Pattern

우리의 과제

http://modelmapper.org

http://modelmapper.org

• 이터너티님의 블로그(http://aeternum.egloos.com)

• 백기선님 블로그 (http://whiteship.me)

• 이미 2005년에 작성된 토비님의 아티클Domain Model vs. DTO : http://toby.epril.com/?p=99

• 실전 코드가 있는 자바지기님의 DTO에 관한 최근 아티클 : http://www.slipp.net/wiki/pages/viewpage.action?pageId=2031636

• Javacan님의 DDD 발표자료 : http://javacan.tistory.com/entry/DDD-%EC

%8C%A9%EA%B8%B0%EC%B4%88-%EC%84%B8%EB%AF%B8%EB%82%98-%EB%B0%9C%ED%91%9C-%EC%9E%90%EB%A3%8C

좋은 자료

http://aeternum.egloos.com

http://aeternum.egloos.com

http://whiteship.me/

http://whiteship.me/

http://toby.epril.com/?p=99




http://www.slipp.net/wiki/pages/viewpage.action?pageId=2031636

http://www.slipp.net/wiki/pages/viewpage.action?pageId=2031636

http://javacan.tistory.com/entry/DDD-%EC%8C%A9%EA%B8%B0%EC%B4%88-%EC%84%B8%EB%AF%B8%EB%82%98-%EB%B0%9C%ED%91%9C-%EC%9E%90%EB%A3%8C




• Clean Code (Chapter 6 객체와 자료 구조)

• http://codebetter.com/gregyoung/2010/02/16/cqrs-task-based-uis-event-sourcing-agh/

• http://martinfowler.com/bliki/CQRS.html

참고

http://codebetter.com/gregyoung/2010/02/16/cqrs-task-based-uis-event-sourcing-agh/






http://martinfowler.com/bliki/CQRS.html


감사합니다.

시간이 부족해 발표하지 못한 내용입니다.Domain Model Everywhere에서

DTO, CQRS를 사용해 Pure Domain Model로 리펙토링되는 상황을 연출해 보았습니다.

Entity and View

• Entity는 비즈니스 로직을 위한 것이지 View를 위한 것이 아니다.

Entity and View

회원ENTITY+BIZ LOGIC

Entity and View

회원ENTITY+BIZ LOGIC+ViewA로직+ViewB로직+ViewC로직

.....

View A

View B

View C

그래 나 뚱뚱하다!

Entity and View

• Entity가 View 로직 때문에 뚱뚱해진다.

• OSIV 사용

• JSON, XML 문제점• 객체 그래프를 찾아 가는 것을 View개발자가 힘들어 한다. ex) member.getCard().getData()...

Entity and View

• View를 위한 DTO 가 필요한 시점

Entity and View

회원ENTITYBIZ LOGIC+ViewA로직+ViewB로직+ViewC로직

.....

View A

View B

View C


Entity and View

회원ENTITYBIZ LOGIC

View A

View B

View C

회원DTO+ViewA로직+ViewB로직+ViewC로직

Entity and View


View A

View B

View C


View D 회원관리DTO+ViewD로직

Entity and View

• View와 비즈니스 로직의 요구사항 다름

• Entity = 비즈니스 로직

• DTO = VIEW

뚱뚱한 Service

• 이제는 Service가 뚱뚱해 진다.

뚱뚱한 Service


.....

View A

View B

View C


뚱뚱한 Service


.....

View A

View B

View C


회원Service+회원등록()+회원수정()+회원탈퇴()

+getMember()

뚱뚱한 Service



View A

View B

View C


+getMemberDTO()

뚱뚱한 Service


View A

View B

View C




+getMemberDTO()+getMemberManageDTO()

...DTO()


뚱뚱한 Service

• 음... 이건 어떻게 하지?

뚱뚱한 Service

• 등록,수정,삭제 같은 명령어와 조회용 쿼리를 분리하자!

뚱뚱한 Service


View A

View B

View C





...DTO()


뚱뚱한 Service


View A

View B

View C



회원CommandService+회원등록()+회원수정()+회원탈퇴()

회원QueryService+getMemberDTO()

+getMemberManageDTO()...DTO()

CQRS

• Command Query Responsibility Segregation

• 등록,수정,삭제 같은 명령어와조회용 쿼리를 분리!

CQRS

• QueryService

• CommandService

Command Query

변경

검증

비즈니스 로직수정

가끔 변경됨 자주 변경됨

O X

O X

CQRS 적용 전출처 : http://martinfowler.com/bliki/CQRS.html



CQRS 적용 후출처 : http://martinfowler.com/bliki/CQRS.html



멀티 모듈인 경우

• 멀티 모듈인 경우를 생각해보자

CORE

FRONT ADMIN BATCH



...DTO()

CORE

FRONT ADMIN BATCH



+getMemberManageDTO()...DTO()

CORE

FRONT ADMIN BATCH



+getMemberManageDTO()+getFrontMemberDTO()+getBatchMemberDTO()


• 각각의 모듈에 특화된 Query

• Core에 두는 것이 옳은가?

CORE

FRONT ADMIN BATCH



+getMemberManageDTO()+getFrontMemberDTO()+getBatchMemberDTO()

CORE

FRONT ADMIN BATCH



회원FrontQueryService회원BatchQueryService

회원AdminQueryService

CORE

FRONT ADMIN BATCH


회원FrontQueryService 회원BatchQueryService회원AdminQueryService


• 모듈에 특화된 조회서비스는 해당 모듈에서 관리

• Core모듈의 복잡성이 줄어듬

• 비즈니스 로직은 Core에서 관리

감사합니다.

Documents

좌충우돌 ORM 개발기 | Devon 2012