Eternity's Chit-Chat

aeternum.egloos.com



Open Session in View Pattern Software Design

Open_Session_In_View_Pattern.pdf

현재 참여 중인 프로젝트에서 JPA(Java Persistence API) 구현체로 Hibernate 사용하고 있습니다.

문서는 프로젝트 진행 Open Session in View 패턴적용과 관련해서 논란이 되었던 가지 이슈를 정리한 것으로 전체적으로 Open Session in View 패턴의 개요 ,Spring 프레임워크 지원 기능, Open Session in View 패턴 적용 시의 주의사항으로 구성되어 있습니다.

문서의 마지막 부분은 Open Session in View 패턴에 대한 다분히 개인적인 견해를 중심으로 작성한 것이므로 감안하시고 주시면 감사하겠습니다.


덧글

  • holyeye 2011/06/29 02:01 # 삭제

    osiv 에 관해서 이렇게 명확하게 정리된 자료는 처음입니다
    정말 너무나도 큰 도움이 되었습니다
    이터너티님의 소프트웨어 설계에 관한 열정과 깊이에 감사드립니다!
  • 이터너티 2011/07/01 17:27 #

    긴 글인데 끝까지 참고 읽어 주셔서 오히려 제가 감사드립니다.
  • 토비 2011/06/29 14:10 # 삭제

    얼른 정리해서 책으로 내시라니까요.
  • 이터너티 2011/07/01 16:15 #

    요즘에 프로젝트때문에 시간이 너무 없네요. ㅠㅠ 이것도 겨우 겨우 썼어요.
    한국 오셨다는데 월요일에 뵈요. ^^
  • ologist 2011/06/30 00:07 # 삭제

    잘 읽었습니다. 어쩜 이렇게 글을 잘 쓰시는지...ㅎㅎㅎ
    나중에 변종(?) 레이어 아키텍처를 한번 공유하겠습니다.
  • 이터너티 2011/07/01 17:28 #

    기대하고 있을께요.
    정리되면 한 번 보여주세요 ^^
  • 박성철 2011/06/30 09:05 # 삭제

    이건 사기입니다.
    그냥 "개인적"인 견해를 덧붙힌 몇가지 논점 정리라고 소개하셔서 가볍게 클릭했는데....
    회사에서 JPA를 두고 종교 전쟁이라도 일어나고 있나요? 이런 어마어마한 글을 *단지* 그런 이유로 작성하고 말입니다.
    읽으면서 지식의 방대함과 치밀함에 한번 놀라고 사람에게 대한 애정과 겸손이 느껴져 한 번 더 놀랍니다.
    P.S. 책 기대하겠습니다. 정말로 말씀 드리는 겁니다.
  • 이터너티 2011/07/01 17:56 #

    사기라고 하셔서 깜짝 놀랐어요 ^^;;
    과분한 칭찬 감사드립니다. 책은... 일이 좀 줄어야 준비할 수 있을 것 같네요. ㅠㅠ
  • 백기선 2011/06/30 10:32 # 삭제

    우왕... 멋지시네요. 정말 책 쓰셔야 될 것 같아요.
  • 이터너티 2011/07/01 17:57 #

    기선씨도 어서 책 한권 써주세요. ^^
  • 민달 2011/06/30 13:06 # 삭제

    패턴과 하이버네이트와 스프링을 활용한 구현에 대한 상세한 내용도 흥미로웠지만, 개인적으로 의존성 문제에 대한 탁월한 시각을 엿보는 즐거움이 매우 컷습니다. 메신저로 말씀 드렸듯이 가슴을 시원하게 하는 냉수 같은 글이었던 것 같네요. 집에서 조용히 다시 한번 읽으며 음미해보고 싶은 글입니다.

    정말 잘 읽고 갑니다.
  • 이터너티 2011/07/01 17:59 #

    저도 이번 글 쓰면서 의존성에 관해서 다양한 관점에서 생각을 하게 되어 도움이 많이 되었던 것 같아요.
    나중에 한 번 민창 과장님이랑 관련해서 이야기해 보고 싶네요. ^^
  • 최영목 2011/07/07 14:40 # 삭제

    좋은 글 감사합니다. ^^ 항상 이터너티님께 많을 것을 배워가고 있네요^^

    제가 아직 경력도 짧고 경험도 미흡해서 잘못 이해하고 있는 부분이 있지 않나 생각합니다.
    제가 이해하고 있는 부분을 말씀드리겠습니다.

    하이버네이트의 Entity를 DDD의 Entity로 바라본다면 말씀하신 Open Session in View Pattern을 활용하면 좋은 해법이 될 것 같습니다.
    하지만 저는 하이버네이트의 Entity를 DDD의 Entity로 해석하면 무리가 있지 않나 생각됩니다.
    말씀하신대로 레이어를 구분할 때 도메인 로직과 영속성 로직이 분리되어야 된다고 하셨습니다. 하지만 하이버네이트의 Entity의 경우 POJO를 표방하고 있지만 실은 도메인과 영속성이 혼합된 형태의 Entity라고 생각됩니다.
    그 예로 Entity임에도 불구하고 애노테이션 형태로 데이터베이스에 의존적인 내용들이 기술되기 때문이죠. 또한 @Transient (JPA 1.0 스펙)을 제공하고 활용한다는 것은 도메인의 원래 목적인 행위를 표현한다기보다는 (특히 데이터베이스)정보를 표현하는 경우로 더 많이 쓰인다는 것이죠.

    또한 레이어의 목적에 따라 예제로 설명하신 AlbumRepository의 구현체인 HibernateAlbumRepository를 IbatisAlbumRepository로 바꾸더라도 동일하게 동작을 해야 합니다. 하지만 현재 구조에서는 IbatisAlbumRepository로 바꾸었을 경우 과연 Open Session in View Pattern을 동일하게 적용할 수 있느냐?라는 의문이 생깁니다.

    결국 제가 말하는 가장 중요한 핵심은 과연 화면(view)에서 필요한 데이터를 표현하기 위해서 도메인 자체 또는 도메인의 getter메서드를 노출시키는 것이 옳은 일이냐 하는 것입니다. 물론 실무에서 일을 하다보면 여러가지 사유(특히 일정)때문에 또는 너무 많은 정보 객체의 생성을 회피하기 위해서 도메인 자체를 리턴하는 경우가 굉장히 많습니다.
    하지만 의미론적으로만 접근을 했을 경우 해당 도메인의 정보를 외부에 노출하는 경우 interface를 통해서 제공을 하고, 그 interface의 구현체를 뷰에 노출시켜야 하지 않나 생각됩니다. 이 부분은 Allen Holub의 실전 코드로 배우는 디자인패턴의 내용과 동일 인물의 Why getter and setter methods are evil
    (http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html?page=1)의 영향을 많이 받았습니다.

    Application 레이어(또는 Service 레이어)에서 도메인을 리턴한다는 것은 화면(view)에서 어떤 정보를 사용할 지 모른다는 것입니다.
    이는 비즈니스 시나리오를 다시 생각해보면 화면(view)에서 요구하는 정보가 무엇인지도 모르는데 아무거나 다 쓸 수 있는 인터페이스 도출이라는 명목하에 도메인을 리턴하게 되고, 이에 따라 lazy loading에 의한 화면(view)에서 발생하는 문제가 아닌가하는 생각이 듭니다.

    이를 해결할 수 있는 방법은 2가지라고 생각됩니다.
    1. 도메인을 리턴하는 private 메서드를 만들고, 해당 view에서 요구하는 정보 객체를 만들어 인터페이스를 노출시킨다.
    2. Hibernate.initialize로 모두 초기화해서 정보를 넘겨준다. (성능문제 발생) : 이는 말씀하신 Open Session in View Pattern을 적용하더라도 ajax통신(json)을 통해 view에서 호출하면
    결국 2번과 동일하게 동작하게 됩니다. 정보를 쓰지 않아도 그렇습니다.

    조금 논외이긴 합니다만 정석적인 TDD로 개발을 한다면 도메인을 리턴하는 경우는 없을 것입니다. 프로젝트에서 TDD를 완벽하게 적용할 수도 없고, 우리가 알고 있는 실무에서 이론적인 내용을 완벽히 접목시키는 일 또한 어려운 일이라 생각합니다.

    하지만 이터너티님께서 올려주신 Open Session in View Pattern은 말씀하신대로 단일 JVM에 도메인 모델 패턴에 따라 개발할 때 아주 좋은 패턴임은 틀림이 없습니다.

    제가 글솜씨도 없어서 두서없고, 표현을 잘 하지 못하는 부분이 많이 있습니다. 이 점 죄송하게 생각합니다.
    혹시라도 제가 잘못 이해하거나 오해하고 있는 부분이 있다면 업계 선배님의 따듯한 마음으로 조언을 해주시면 새겨듣도록 하겠습니다. 감사합니다. ^^
    (제가 논점(context)을 유지하는 능력이 많이 부족합니다. ㅠㅠ)
  • 이터너티 2011/07/21 23:54 #

    최영목님 안녕하세요. 제가 요즘 프로젝트가 바빠서 답변이 조금 늦어졌네요. ^^;;

    위에 적으신 내용에 대해서 제가 생각하는 바를 답변 형식으로 적겠습니다.

    다른 의문사항이 있으면 질문 주시기 바랍니다. ^^

    “하이버네이트의 Entity를 DDD의 Entity로 해석하면 무리가 있지 않나 생각됩니다. “
    -> 하이버네이트의 Entity는 DDD의 Entity일 수도 있고 아닐 수도 있습니다. 하이버네이트의 Entity를 단순히 DB 테이블의 데이터를 담는 용도로 사용한다면 DDD에서 말하는 Entity가 아니겠지만 실제 도메인의 개념을 표현하는 식별성과 추적성을 가진 클래스로 모델링한다면 DDD에서 말하는 Entity가 되겠지요. DDD 책을 보시면 아시겠지만 DDD의 Entity는 클래스뿐만 아니라 XML이나 DB 테이블의 레코드로 변형된 형태를 통칭하는 말입니다. DDD는 설계 패러다임이고 하이버네이트는 구현 프레임워크입니다. 클래스의 설계를 어떻게 하느냐에 따라 DDD의 Entity가 될 수도, 아닐 수도 있지만 그렇다고 해서 반드시 하이버네이트에서 말하는 Entity가 DDD의 Entity가 아니다라고 말할 수는 없는 것이죠. 위에 말씀하신 것처럼 단지 매핑 정보를 어노테이션을 사용해서 표현 했기 때문에 Entity가 아니라고 한다면 같은 클래스를 XML 형식의 매핑 파일로 변환한다면 Entity가 되는 것일까요? DDD의 Entity는 도메인을 구성하는 개념들 중에 추적성과 식별성이 중요한 어떤 것입니다. DDD의 의미를 명확하게 설계에 반영한 후 하이버네이트에서 말하는 Entity를 사용해서 구현한다면 그것은 DDD의 Entity가 됩니다. 그렇지 않다면 하이버네이트의 Entity로 구현한다고 해서 DDD의 Entity가 될 수는 없겠죠. 문제는 어떤 도구를 사용하느냐가 아니라 어떤 사람이 설계를 하느냐에 달려 있다고 보시는 것이 맞습니다.

    “또한 레이어의 목적에 따라 예제로 설명하신 AlbumRepository의 구현체인 HibernateAlbumRepository를 IbatisAlbumRepository로 바꾸더라도 동일하게 동작을 해야 합니다.”
    -> 하이버네이트는 ORM이고 iBatis는 SQL Mapper입니다. OSIV는 ORM과 관련된 패턴이므로 iBatis로 바꾼다면 당연히 동작하지 않으며 동작할 필요도 없습니다. 제가 쓴 글에서 영속성 메커니즘을 하이버네이트에서 iBatis로 바꾸더라도 뷰가 변경되지 않는다라는 것을 OSIV를 그대로 사용할 수 있다는 것으로 착각하신 것 같습니다.

    “결국 제가 말하는 가장 중요한 핵심은 과연 화면(view)에서 필요한 데이터를 표현하기 위해서 도메인 자체 또는 도메인의 getter메서드를 노출시키는 것이 옳은 일이냐 하는 것입니다. ... 의미론적으로만 접근을 했을 경우 해당 도메인의 정보를 외부에 노출하는 경우 interface를 통해서 제공을 하고, 그 interface의 구현체를 뷰에 노출시켜야 하지 않나 생각됩니다”
    -> 예를 들어 name, address, age라는 3가지 속성을 가진 Person이라는 클래스가 있다고 해보겠습니다. 이 때 화면 A는 name과 address를, 화면 B는 name과 age를, 화면 C는 address와 age를, 화면 D는 name, address, age 3가지 속성 모두를 표현한다고 가정하겠습니다. 그렇다면 각 화면에 맞게 인터페이스를 따로 만들어야 할까요? 화면 A에 age를 반환하는 인터페이스를 노출하는 것은 캡슐화 위반일까요?
    일정 때문에 라고 하셨지만 이것은 일정의 문제가 아니라 유지보수의 문제입니다. 화면에 따라 필요한 정보를 제공하는 인터페이스를 각각 만든다면 그것이 정말로 캡슐화를 지키는 것일까요? 화면에 종속적인 수 많은 인터페이스를 유지보수하는 것이 정말 의미가 있을까요? 현재의 자바 기반의 모든 뷰 기술은 Java Beans 스펙을 이용하여 필요한 정보를 출력합니다. 따라서 getter를 추가할 수 밖에 없습니다.
    논점은 다음과 같습니다. 화면에 따라 필요한 정보만 제공하는 개별 인터페이스를 만들 것인가, 아니면 모든 getter를 가진 인터페이스를 만들어서 공용으로 사용할 것인가? 만약 모든 getter를 가진 인터페이스를 사용한다면 도메인 객체를 사용하는 것과 무슨 차이가 있을까요?
    얼핏 보면 좋아 보이는 주장들이 있지만 큰 그림에서 보면 형편없는 것들이 많이 있습니다. 뷰에 인터페이스를 노출해야 한다는 원칙이 그것이죠. getter를 노출해서는 안되는 것은 도메인 레이어에서의 이야기입니다. 도메인 레이어에서 로직을 처리하기 위해 getter를 노출하는 것은 캡슐화 위반입니다. 하지만 앞에서 이야기한 것처럼 현재의 대부분의 뷰 기술은 getter를 요구하며 단지 뷰를 위한 인터페이스를 만드는 것은 현실성도 없고 캡슐화를 지키지도 못하므로(뷰가 리플렉션 메커니즘에 의존한다는 사실을 다시 한번 생각해 보시기 바랍니다) 현실성이 없습니다.

    “Application 레이어(또는 Service 레이어)에서 도메인을 리턴한다는 것은 화면(view)에서 어떤 정보를 사용할 지 모른다는 것입니다. “
    -> 관심사의 분리라는 측면에서 본다면 화면에서 필요한 정보가 무엇인지 모르는 것이 더 좋습니다. 이 부분에 대해서는 위 글에 정리되어 있습니다.

    “이를 해결할 수 있는 방법은 2가지라고 생각됩니다.
    1. 도메인을 리턴하는 private 메서드를 만들고, 해당 view에서 요구하는 정보 객체를 만들어 인터페이스를 노출시킨다.”
    -> 인터페이스를 노출시키는 것에 대한 문제는 앞에서 말씀 드렸습니다. 정보 객체는 DTO를 말씀하시는 것 같은데 앞에서 말씀 드린 화면 별로 DTO를 만든다고 생각해 보면 만약 Person의 코드를 리팩토링하려면 화면별 DTO도 리팩토링해야 하며 Person과 DTO 간의 매핑 코드 역시 수정해야 합니다. DTO를 사용하는 프로젝트를 경험해 보시지 못한 것 같은데 DTO는 유지보수에 있어 최악의 선택입니다.

    “2. Hibernate.initialize로 모두 초기화해서 정보를 넘겨준다. (성능문제 발생) : 이는 말씀하신 Open Session in View Pattern을 적용하더라도 ajax통신(json)을 통해 view에서 호출하면
    결국 2번과 동일하게 동작하게 됩니다. 정보를 쓰지 않아도 그렇습니다.”
    -> 동일하지 않습니다. Hibernate.initialize()로 초기화한다는 것은 화면에서 어떤 정보를 출력할 지 미리 알고 있어야 한다는 것을 의미합니다. 화면이 변경되면 Hibernate.initialize()로 초기화하는 부분 역시 변경되어야 하죠. 이 방법은 개념적인 결합이 발생합니다. 이에 비해 OSIV는 개념적인 결합이 발생하지 않습니다.

    “조금 논외이긴 합니다만 정석적인 TDD로 개발을 한다면 도메인을 리턴하는 경우는 없을 것입니다. 프로젝트에서 TDD를 완벽하게 적용할 수도 없고, 우리가 알고 있는 실무에서 이론적인 내용을 완벽히 접목시키는 일 또한 어려운 일이라 생각합니다.”
    -> TDD는 도메인 객체를 리턴하느냐와는 무관합니다. OSIV는 시스템의 전반적인 아키텍처와 관련된 것이며 TDD는 개별 기능을 설계하고 구현할 때 신뢰성을 높이고 설계 품질을 향상시키며 스트레스를 줄이는 방법입니다. 정석적인 TDD로 개발을 할 경우 도메인을 리턴하는 경우가 없다고 하셨지만 어떤 의미인지 이해하기가 힘듭니다. 저 같은 경우 현재 TDD로 개발을 하고 있지만 도메인 객체를 리턴하도록 개발하고 있습니다. OSIV와 TDD는 무관한 내용이므로 정확하게 어떤 경우를 말씀하시는 것인지 알려 주시면 답변 드리도록 하겠습니다. TDD는 이론이 아니고 실무입니다. 프로젝트에서 가장 먼저 적용해야 하는 기술이 있다면 TDD라고 생각하며 실무에 적용하기 가장 적절한 기술이 있다면 TDD라고 생각합니다.
  • 최영목 2011/08/03 21:26 # 삭제

    답변 감사드립니다. 댓글의 댓글은 가능하지 않네요 ^^;;

    선배님께서 말씀해주신 내용으로 저의 좁았던 시야가 조금 더 열리는 느낌입니다. 또한 이번에 번역된 DDD책을 휴가기간 중에 읽고 있습니다. (영어가 약해서 원서는 읽었으나 머리에 거의 안들어가더군요 ㅠㅠ) 아마도 이 책도 다 읽고, 좀 더 경험이 쌓여야 이터너티님께서 말씀하신 내용을 제대로 이해할 수 있을 것 같습니다. 마치 책을 처음 읽을 때와 두번째 읽는 느낌의 차이라고나 할까요? (이는 전적으로 저의 실력미달입니다. ^^;)

    앞으로도 좋은 글 계속 부탁드리며, 선배님의 글이 저와같은 후배들에게 큰 힘이 된다는 것을 말씀드리고 싶습니다. 예의없었던 질문에 성실히 답변해주셔서 감사합니다.

  • 이터너티 2011/08/09 01:42 #

    제가 아는 내용이면 최대한 답변 드리겠으니 궁금한 부분이 있으면 언제라도 질문하셔도 무방합니다. ^^
    제 부족한 글에 관심 가져 주셔서 감사드리고 조금이나마 도움이 되셨으면 좋겠네요.
  • 최영목 2011/07/07 17:45 # 삭제

    궁금한게 있어서 장문의 댓글을 남겼는데 다시 보니 글의 요지와 context가 많이 벗어난 질문이었습니다. 후배의 궁금증이 너무 커서 업계 선배님께 결례를 범하게 되었네요. 정말 죄송합니다.
  • 최빈 2013/08/23 10:36 # 삭제

    와.. 진심으로 감사합니다 ~!!
    어제 하루종일 지연로딩과 세션전파에 대해서 어떻게 처리하는것이 최선인지 고민을 했습니다~

    너무너무 좋은글 감사합니다!!
  • 최빈 2013/08/23 14:56 # 삭제

    현재 하이버네이트 공부 중인 사람입니다.. 제가 생각을 좀 해봤는데,

    제가 우매해서 이런생각을 한것인지, 아니면 제 생각이 맞는지에 대한 고민이 생겨 선배님께

    질문드립니다.

    올려주신 pdf 를 읽으면서 늦초기화에 대해 많이 고민을 했습니다..

    고민을 하다가 한발짝 떨어져서 생각을 해보니,
    올려주신 pdf 파일의 album예제는 늦초기화에 적합하지 않다는 생각이 들었습니다.

    뷰(jsp)에서 앨범명. 가수명. 수록곡 을 바로 보기를 원하는데 ,
    이 경우에는 하이버네이트의 늦초기화 기능을 쓰는것 자체가 적합하지 않다고 생각합니다.

    화면에 보여줄 데이터가,

    앨범뿐 아니라, 가수명. 수록곡을 늦게 초기화해서 보여주는게 아니라 즉석에서 보여주도록
    되어있습니다.

    허면. 늦초기화가 아닌, FetchType.EAGER 를 통해 즉시 가져오는게 맞지 않나 생각을 해보았습니다.

    요청당세션 일때, 한 요청(첫번째요청)에서 안보여줘도 되고 단지 식별자만 갖고 있어도 되는 데이터라면
    늦초기화를 쓰는게 적합하고, 두번째 요청에서 첫번째 요청 때 가져왔단 엔티티에서 식별자만 갖고 있던 프록시를 초기화하려할 때, 재진입이나 병합을 쓰는게 적합한것 같다는 생각이 듭니다..

    아직 머릿속에서 생각이 정리가 안된채 남긴 댓글입니다.. ㅠ.ㅠ

    그리고 올려주신 PDF 는 정말 많은 공부가 되었습니다 감사합니다.
  • 이터너티 2013/08/24 11:14 #

    최빈님 안녕하세요.

    만약 album이 예제에 수록된 하나의 뷰에서만 사용된다면 말씀하시는 것이 맞습니다.

    하지만 대부분의 경우 다양한 뷰에서 화면 표현을 위해 album을 사용하겠죠.

    예를 들어 앨범의 목록만 보여주는 뷰가 있을 수 있고, 앨범과 아티스트를 함께, 앨범과 수록곡을 함께, 그리고 여기에서 설명드린 뷰처럼 앨범, 아티스트, 수록곡을 함께 보여주는 뷰들이 있을 수 있죠.

    자, 이 경우 fetch 전략을 어떻게 설정해야 할까요?

    두 가지 접근 방법이 있습니다.

    1. 모든 뷰에서 자신이 필요한 부분을 필요한 시점에 lazy loading한다.
    2. 모든 경우에 앨범, 아티스트, 수록곡을 항상 eager loading한다.

    자세한 부분까지 설명을 드릴 수는 없겠지만 두 방법 모두 DB 접근을 최대한 줄여 성능을 높인다는 동일한 목적을 가집니다.

    제가 말씀드리고 싶은 것은 요청당 세션이더라도 여러 뷰에서 사용될 경우 lazy loading을 해야하는 경우가 매우 많다는 점입니다.

    엔티티에 설정되는 fecth 전략은 성능 최적화에 큰 영향을 미치는 전역 설정이므로 여러 유스케이스를 기반으로 가장 적절한 전략을 수립해야 합니다.

    앨범, 아티스트, 수록곡들이 다양한 화면에서 부분적으로만 표현된다면 어떻게 할까요?

    lazy loading을 해서 필요한 부분을 필요한 시점에 로딩하도록 할 수도 있고, 성능 이슈가 크지 않다면 사용되지 않더라도 eager loading을 해서 전체를 다 가져오되 필요한 부분만 사용하도록 해도 되겠죠.

    단순히 하나의 화면만을 놓고 판단해서는 안되는 것이죠.

    참고로 JPA에서는 엔티티에 lazy를 설정해도JPQL을 이용해 이 설정을 무시하고 join을 걸 수 있도록 허용하므로 필요한 경우 전체를 다 가져올 수는 있습니다.

    제 글에서는 lazy loading과 관련된 이슈를 중심으로 최대한 단순하게 설명하기 위해 별다른 부연설명을 하지 않았습니다만 그 배후에는 앨범이 다양한 뷰에서 사용되고 있다고 가정하시면 될것 같습니다.

    도움이 되셨는지 모르겠네요. ^^
  • 최빈 2013/08/26 09:17 # 삭제

    자세한 답변 감사합니다 ^^
    이터니티님 답변을 읽고나니,
    제가 질문했을 당시, 왜 한 화면에만 얽매여서 생각했는지 모르겠습니다 -_-;

    당연히 여러 뷰에서 앨범 관련 정보를 보여줄테고,
    말씀해주신대로 어떤 뷰에서는 앨범.아티스트 정보만, 어떤 뷰에서는 앨범만 어떤뷰에서는 전체를.

    이런식으로 뷰가 구성되는게 당연한것일텐데 말이죠 .. 그리고 말씀해주신대로 이런식으로

    뷰가 구성됐다면, 당연히 늦초기화가 여러모로 큰 이점으로 다가올거라 생각이 됩니다..

    제가 생각이 너무 짧고 좁았네요~ 다시한번 감사드립니다 이터니티님
  • 이터너티 2013/08/26 23:05 #

    아닙니다.
    ORM을 처음 적용할 때 모든 사람들이 가지게 되는 고민이니 질문 주시는게 당연합니다. ^^
    궁금한 점이 있으시면 또 질문 주세요.
  • 유끄리 2014/09/04 19:39 # 삭제

    정말 좋은 aticle이었습니다.
  • 아틴 2015/09/17 16:24 # 삭제

    와 정말 충격적으로 좋은 내용입니다.
    이런 블로깅을 해주시는 것에 감사드립니다.

    슬라이드 쉐어에 올린 DDD 자료도 보았는데 너무 함축적이라 그런지 큰 느낌이 없었는데
    블로그의 글들은 하나 하나가 정말 주옥 같으시네요.
  • 이터너티 2015/09/17 20:44 #

    충격적으로 좋은 답글이네요. ^^
    좋게 평해주셔서 감사합니다.
    덕분에 기분이 좋아졌어요. ㅎㅎ
  • 황대민 2016/05/23 20:23 # 삭제

    JPA 입문과정을 학습한후 open session in view 에 대해서 찾아보던 도중 이터니티님의 블로그를 보게 되었네요. PDF를 읽는데 1시간이 넘게 걸렸습니다;; 단순히 open session in view 패턴 뿐만아니라
    대부분 고민하고 있는 아키텍처 패턴에 대해서 정리된 부분에 감탄을 금치 못하고 있습니다~
    좋은글 작성해주셔서 감사합니다!!
※ 로그인 사용자만 덧글을 남길 수 있습니다.