좌충우돌 ORM 개발기 2012 DAUM DEVON
•
16 gostaram•2,517 visualizações
다음 데브온에서 발표한 좌충우돌 ORM 발표입니다. JPA의 필요성, 스프링 데이터 JPA, QueryDSL을 활용한 개발 방법등을 설명합니다.
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (14)
Semelhante a 좌충우돌 ORM 개발기 2012 DAUM DEVON
Semelhante a 좌충우돌 ORM 개발기 2012 DAUM DEVON (20)
좌충우돌 ORM 개발기 2012 DAUM DEVON
- 2. 목차 • 프로젝트 구조와 모순 • Why ORM? • DEMO 프로젝트 • ORM 적용시 고민할 2가지 구조 • Domain Model Everywhere • DTO, Pure Domain Model
- 3. 프로젝트 구조와 모순
- 4. 화면 중심 프로젝트 • 화면 중심으로 프로젝트 구조를 구성 • View 단위로 개발자 투입 • Service, Dao, Entity를 각자 만들어 써야함, 공 유하는 것은 허용하지 않음
- 5. 회원관리 화면 Package controller (MemberController) service (MemberService) dao (MemberDao) entity (Member) 상품 관리 화면 Package controller (ProductController) service (ProductService) dao (ProductDao) entity (Product)
- 6. 회원관리화면 상품관리화면 주문관리화면 A개발자 B개발자 C개발자
- 7. 회원관리화면 상품관리화면 주문관리화면 A개발자 B개발자 C개발자 MemberControll MemberServi MemberDa MemberEntit ProductControlle ProductServi ProductDao ProductEntity OrderController OrderService OrderDao OrderEntity
- 8. 회원관리화면 상품관리화면 주문관리화면 A개발자 B개발자 C개발자 MemberControll MemberServi MemberDa MemberEntit MemberDa MemberEntit MemberDa MemberEntit ProductControlle ProductServi ProductDao ProductEntity OrderController OrderService OrderDao OrderEntity ProductDao ProductEntity 중복!!!
- 9. • 프로젝트가 계속 진행되면...
- 10. • 같거나 유사한 Query가 무수히 나타남 • 회원정보 조회의 경우 11번의 거의 동일한 쿼 리 발견 • 수정이 아주 어려움 • 월화수목금금금... --;
- 11. 화면중심 프로젝트 구조는 수 많은 중복을 만든다.
- 12. 일반적인 프로젝트 • 데이터와 비지니스 로직을 중심으로 프로젝트를 설계한다.
- 13. 회원관리, 상품관리 controller - MemberController - ProductController service - MemberService - ProductService dao - MemberDao - ProductDao entity - Member - Product MemberController ProductController MemberService ProductService MemberDao ProductDao Member Product
- 15. ADMIN BATCH FRONT Member Dao Member Entity Member Dao Member Entity Member Dao Member Entity 중복!!!
- 17. CORE 멀티 모듈 프로젝트 Member Dao Member Entity Member Dao Member Entity Member Dao Member Entity FRONT ADMIN BATCH
- 21. 데이터 불일치 • CORE로 통합시 또 다른 문제 발생 • SQL의 Projection은 각 모듈의 비즈니스 로직 과View에 최적화 • findFrontMember findAdminMember ...???
- 22. 데이터 불일치 해결 방안 • Row단위로 전체 조회 • 특별한 경우만 최적화 • 파레토법칙(20/80법칙)
- 23. 하지만...
- 25. class Member { Card card; Manager manager; Card getCard(); Manager getManager(); } 회원 회원관리직원 멤버십카 드
- 26. Join의 경우 회원 회원관리직원 멤버십카 드 Front SQL : Member Join Card Code : member.getCard() member.gerManager() ???
- 27. Join의 경우 NullPointException!!! NullPointException!!! NullPointException!!! NullPointException!!!
- 28. Join의 경우 회원 회원관리직원 멤버십카 드 Admin SQL : Member Join Manager Code : member.getManager() member.getCard() ???
- 29. Join의 경우 NullPointException!!! NullPointException!!! NullPointException!!! NullPointException!!!
- 30. Join의 경우 회원 회원관리직원 멤버십카 드 Batch SQL : Member Join Manager Join Card Code : member.getManager(), member.getCard() 불필요한 조인, 성능 낭비
- 32. Join의 경우 • Entity가 실행한 SQL에 데이터를 의존 • Entity에 구멍이남 • 결국 비즈니스 로직이 SQL에 의존 • 모든 데이터를 메모리에 올리는 것은 현실적 이지 않음
- 33. 프로젝트 구조와 모순의 결론 • Entity가 SQL에 의존 • 구멍난 Entity • 신뢰할 수 없는 Entity • 진정한 의미의 계층 분할이 어려움
- 34. Why ORM?
- 35. ORM을 사용하는 이유 • Projection 문제 • Join 관련 데이터 연결 문제 • Entity 데이터에 대한 신뢰 • 제대로 된 프로젝트 구조 • CRUD SQL좀 알아서 해줬으면 • 진정한 객체 지향 개발 가능 • 도메인 주도 개발 가능
- 36. SQL을 사용해야 하는 이유 • 우리가 사용 중인 DB는 RDB다!!! • 통계 데이터 • 아주 복잡한View
- 37. ORM을 사용하는 진짜 이유! 컴퓨터가 할 수 있는 일을 더이상 사람이 하지 말자 나는 SQL MAPPER가 아니다!
- 38. JDBC xBatis ORM
- 39. 여기서 잠깐!
- 40. ORM에 관한 오해 Q : OBJECT DB같은 것 아닌가요? 이미 망한 기술로 알고 있는데요?
- 41. ORM에 관한 오해 Q : 성능이 느리다.
- 42. ORM에 관한 오해 Q : ORM을 사용하면 SQL을 못쓴다.
- 43. ORM에 관한 오해 Q : SQL을 몰라도 되나요?
- 44. ORM에 관한 오해 Q : 공부할 내용이 많으면 어쩌지...
- 45. ORM에 관한 오해 Q : 모두 iBatis, myBatis만 사용하는데요? A : 진실은?
- 46. 2012년 8월 한국 구글 검색 myBatis iBatis Hibernate JPA
- 47. 2012년 8월 인도 구글 검색 myBatis iBatis Hibernate JPA
- 48. 2012년 8월 미국 구글 검색 myBatis iBatis Hibernate JPA
- 49. 2012년 8월 전세계 구글 검색 myBatis iBatis Hibernate JPA
- 50. ORM을 사용하고 싶은데 어 떻게 시작하나요? • 공부해야 합니다!
- 51. • JPA? • Hibernate? • SpringDataJPA • QueryDSL
- 52. DEMO 프로젝트
- 53. • 사용된 기술 : JPA2, Hibernate, Spring-Data- JPA, QueryDSL, Spring, Maven • source : https://github.com/holyeye/ devon2012 멤버십 프로젝트
- 54. 회원 카드 회원카드 카드적립 포인트 1 : N N : 1 1 : N 적립률 도메인 모델 Create
- 55. 도메인 객체 @Getter @Setter @Entity public 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 @Entity public class Card extends BaseEntity<Long>{ private String name; private int rate; //적립률 //create public CardPoint createCardPoint(int money) { return new CardPoint(name,money,rate); } }
- 56. @Getter @Entity public 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; } }
- 57. 회원 조회, 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 member where (member.name like '%서%') and member.age > 26
- 58. 회원 등록, SpringDataJPA @RequestMapping("member/saveMember") public String saveMenu(Member member) { memberRepository.save(member); return "redirect:/member/home"; } public interface MemberRepository extends JpaRepository<Member, Long>, QueryDslPredicateExecutor<Member>{ } `
- 59. 회원 수정,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
- 60. 회원카드 결제하기 = ORM 저장 10000만원 결제, 10% 적립
- 61. 회원카드 카드적립 포인트 Domain Driven Design 살짝 맛보기 Aggregate ROOT Aggregate(집합) MemberCard Repository
- 62. 회원카드 결제하기 = ORM 저장 @RequestMapping("memberCard/payMoney") public String payMoney( @RequestParam("memberCardId") MemberCard memberCard, @RequestParam("money") int money) { memberCardService.payMoney(memberCard, money); return "redirect:/memberCard/home"; } @Service @Transactional public 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 ` `
- 63. Spring-Data-JPA 소개 • interface로 Repository 자동 생성 (CRUD, 조회) • simple queries ex) findByName(String name) select * from member where name={name} • pagination • Web Binding • Specifications, QueryDSL지원
- 64. QueryDSL 소개 • type-safe JPA queries - 단단하다 • 단순하고 쉽다. • 지속적인 버전업 • Spring Data에서도 사용가능
- 65. ORM 적용시 고민할 2가지 구조
- 66. • ORM을 적용하는 방법은 크게 2가지 • Domain Model Everywhere • Pure Domain Model
- 67. Domain Model Everywhere vs Pure Domain Model
- 68. Domain Model Everywhere Controller Service Repository Entity +Getter,Setter +BizLogic +ViewLogic King View
- 69. • Domain Model을 모든 Layer에서 적극 사용 하자. • OSIV(Open Session InView) 사용 • Getter, Setter 사용 • DTO는 중복 악마다! Domain Model Everywhere
- 70. • 장점 • 개발하기에 빠르고 편리함 • 단점 • 복잡한View 표현 힘듬 • Domain Model의 Getter, Setter를 노출,View로직 추가 • Domain Model의 순수성이 떨어짐 • XML, JSON, 외부와의 통신API 위험 = 도메인 모델은 생각보다 자주 변함 Domain Model Everywhere
- 71. Domain Model Everywhere Controller Service Repository Entity +Getter,Setter +BizLogic +ViewLogic King View
- 72. Pure Domain Model Controller Service Repository Entity +BizLogic View DTO +Getter,Setter +ViewLogic Converter
- 73. • 도메인모델에 Getter, Setter는 지옥행 • 도메인모델에View로직은 지옥행 • OSIV(Open Session InView)는 지옥행 • 도메인모델을 객체답게 만들어라! Pure Domain Model
- 74. Pure Domain Model Robert C. Martin (uncle bob) 필독서!!!
- 75. OOP 캡슐화, 다형성 내부 변수를 노출하지 않음 일반적으로 Getter, Setter 를 이용해서 내부 변수를 모두 노출 사이비 캡슐화 Pure Domain Model 객체 (Domain Model) 자료 구조 (DTO)
- 76. Pure Domain Model 객체 (Domain Model) + 자료 구조 (DTO)
- 77. Pure Domain Model 객체 (Domain Model) 자료 구조 (DTO) + = 잡종
- 78. Pure Domain Model 잡종 이런 잡종 구조는 새로운 함수는 물론이고 새로 운 자료 구조도 추가하기 어렵다. 양쪽 세상에서 단점만 모아 놓은 구조다. 그러므 로 잡종 구조는 되도록 피하는 편이 좋다. - Clean Code, Chapter 6 객체와 자료구조 -
- 79. • 그럼 어떻게 개발하라고요--; Pure Domain Model
- 80. • CQRS Pattern, DTO 활용 • 도메인 모델 = 비즈니스 로직 • View는 DTO만 사용 Pure Domain Model
- 81. CQRS • Command Query Responsibility Segregation • 등록,수정,삭제 같은 명령어와 조회용 쿼리를 분리!
- 83. Command Query 변경 가끔 변경됨 자주 변경됨 검증 O X 비즈니스 로직수 정 O X
- 84. • 장점 • 순수한 Domain Model • 단점 • DTO를 만드는 것은 귀찮다, 성가시다. 괴롭다. • DTO는 또다른 중복이다. • DTO와 Domain Model의 Convert를 고민해야 한다. Pure Domain Model
- 85. 결론
- 86. 그럼 어떻게 해요?
- 87. 여기서 부턴 지극히 주관적입 니다.
- 88. 순수한 객체 No Getter, Setter! Law of Demeter SRP, DIP, OCP, ISP, LSP 도메인 객체는 순수해야 한다!
- 89. Domain Model Everywhere 객체의 순수성을 파괴하 는 사악한 방법! Getter, Setter 필수 Entity = 자료구조+객체
- 90. 이라고 믿고 살았습니다... 직접 개발해 보기 전까진...
- 91. 진짜 ORM 개발을 해보신 분 은 아시겠지만...
- 92. 도메인 모델만으로 모든View를 표현하는 것은 한계가 있습니다.
- 93. 항상 DTO를 만드는 것은 실용적이지 않습니다.
- 94. 결론 Domain Model Everywhere 로 시작 Domain Model로 처리하기 힘든 복잡하고 특별한 경우에는 CQRS, DTO를 사용
- 95. • Domain Driven Design • Pure Domain Model 을 유지하며 실용적으로 개발하는 방법 • DTO를 생성하는 방법, 활용법 • ex) http://modelmapper.org/ • ex) Builder Pattern 우리의 과제
- 96. • 이터너티님의 블로그(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 좋은 자료
- 97. • Clean Code (Chapter 6 객체와 자료 구조) • http://codebetter.com/gregyoung/ 2010/02/16/cqrs-task-based-uis-event- sourcing-agh/ • http://martinfowler.com/bliki/CQRS.html 참고
- 98. 감사합니다.
- 99. 시간이 부족해서 발표하지 못한 내용입니다. Domain Model Everywhere에서 DTO, CQRS를 사용해 Pure Domain Model로 리펙토링되는 상황을 연출해 보았습니다.
- 100. Entity andView • Entity는 비즈니스 로직을 위한 것이지View를 위한 것이 아니다.
- 102. Entity andView 회원ENTITY +BIZ LOGIC +ViewA로직 View AView A
- 104. Entity andView 회원ENTITY +BIZ LOGIC +ViewA로직 +ViewB로직 +ViewC로직 ..... View A View B View C 그래 나 뚱뚱하다!
- 105. Entity andView • Entity가View 로직 때문에 뚱뚱해진다. • OSIV 사용 • JSON, XML 문제점 • 객체 그래프를 찾아 가는 것을View개발자가 힘들어 한다. ex) member.getCard().getData()...
- 106. Entity andView • View를 위한 DTO 가 필요한 시점
- 107. Entity andView 회원ENTITY BIZ LOGIC +ViewA로직 +ViewB로직 +ViewC로직 ..... View A View B View C 그래 나 뚱뚱하다!
- 108. Entity andView 회원ENTITY BIZ LOGIC View A View B View C 회원DTO +ViewA로직 +ViewB로직 +ViewC로직
- 109. Entity andView 회원ENTITY BIZ LOGIC View A View B View C 회원DTO +ViewA로직 +ViewB로직 +ViewC로직 View D 회원관리DTO +ViewD로직
- 110. Entity andView • View와 비즈니스 로직의 요구사항 다름 • Entity = 비즈니스 로직 • DTO =VIEW
- 111. 뚱뚱한 Service • 이제는 Service가 뚱뚱해 진다.
- 112. 뚱뚱한 Service 회원ENTITY BIZ LOGIC +ViewA로직 +ViewB로직 +ViewC로직 ..... View A View B View C 그래 나 뚱뚱하다!
- 113. 뚱뚱한 Service 회원ENTITY BIZ LOGIC +ViewA로직 +ViewB로직 +ViewC로직 ..... View A View B View C 그래 나 뚱뚱하다! 회원Service +회원등록() +회원수정() +회원탈퇴() +getMember()
- 114. 뚱뚱한 Service 회원ENTITY BIZ LOGIC 회원DTO +ViewA로직 +ViewB로직 +ViewC로직 View A View B View C 회원Service +회원등록() +회원수정() +회원탈퇴() +getMemberDTO()
- 115. 뚱뚱한 Service 회원ENTITY BIZ LOGIC View A View B View C 회원DTO +ViewA로직 +ViewB로직 +ViewC로직 View D 회원관리DTO +ViewD로직 회원Service +회원등록() +회원수정() +회원탈퇴() +getMemberDTO() +getMemberManageDTO() ...DTO() 그래 나 뚱뚱하다!
- 116. 뚱뚱한 Service • 음... 이건 어떻게 하지?
- 117. 뚱뚱한 Service • 등록,수정,삭제 같은 명령어와 조회용 쿼리를 분리하자!
- 118. 뚱뚱한 Service 회원ENTITY BIZ LOGIC View A View B View C 회원DTO +ViewA로직 +ViewB로직 +ViewC로직 View D 회원관리DTO +ViewD로직 회원Service +회원등록() +회원수정() +회원탈퇴() +getMemberDTO() +getMemberManageDTO() ...DTO() 그래 나 뚱뚱하다!
- 119. 뚱뚱한 Service 회원ENTITY BIZ LOGIC View A View B View C 회원DTO +ViewA로직 +ViewB로직 +ViewC로직 View D 회원관리DTO +ViewD로직 회원CommandService +회원등록() +회원수정() +회원탈퇴() 회원 QueryService+getMemberDTO () +getMemberManageDTO() ...DTO()
- 120. CQRS • Command Query Responsibility Segregation • 등록,수정,삭제 같은 명령어와 조회용 쿼리를 분리!
- 122. Command Query 변경 가끔 변경됨 자주 변경됨 검증 O X 비즈니스 로직수 정 O X
- 123. CQRS 적용 전 출처 : http://martinfowler.com/bliki/CQRS.html
- 124. CQRS 적용 후 출처 : http://martinfowler.com/bliki/CQRS.html
- 125. 멀티 모듈인 경우 • 멀티 모듈인 경우를 생각해보자
- 129. 멀티 모듈인 경우 • 각각의 모듈에 특화된 Query • Core에 두는 것이 옳은가?
- 132. CORE FRONT ADMIN BATCH 회원CommandService +회원등록() +회원수정() +회원탈퇴() 회원FrontQueryService 회원BatchQueryService회원AdminQueryService
- 133. 멀티 모듈인 경우 • 모듈에 특화된 조회서비스는 해당 모듈에서 관리 • Core모듈의 복잡성이 줄어듬 • 비즈니스 로직은 Core에서 관리