Open Session in View Pattern에 대한 여러분의 의견은 어떠신가요?

최영목

unread,

Jul 7, 2011, 1:46:18 AM7/7/11

to ks...@googlegroups.com

최근에 제가 존경하는 블로거 중의 한분이신 이터너티님의 글을 읽게 되었습니다.

Open Session in View Pattern(http://aeternum.egloos.com/2798098)

아마 많은 분들이 이 글을 보셨을 것이라 생각됩니다. 여기에 대한 제 생각을 댓글로 남기게 되었습니다.

혹시 제가 잘못 이해하거나 오해하고 있는 부분은 없는지 많이 걱정됩니다. (또는 업계 선배님에 대한 결례는 아닐런지...)

여기에 대한 다른 분들의 의견은 어떠신지요?

아래는 제 댓글의 전문입니다.

----------------------------------------------------------------------------------------------------------------------------------------------

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

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

제가 이해하고 있는 부분을 말씀드리겠습니다.

하이버네이트의 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)을 유지하는 능력이 많이 부족합니다. ㅠㅠ)

Sungchul Park

unread,

Jul 7, 2011, 4:29:21 AM7/7/11

to ks...@googlegroups.com

ㅎㅎ
장문의 글을 남기셨네요.

저도 몇가지 감상문을 블로그에 써 볼까 했는데 제 생각과 관련된 부분도 언급하셨으니 여기서 풀어보겠습니다. (짧게요).

먼저 저는 조영호님이 쓰신 글에는 생략된 배경 맥락이 있다고 생각합니다.

Domain을 View까지 노출한다.
Annotation이 마크된 객체도 POJO다.

만약 이 두 가지까지 다루었다면, 꼼꼼하신 성격에, 40여 페이지가 아니라 200 페이지짜리 글을 쓰셨을 것 같네요. 사실 조영호님의 글이 이 두 가지 부분에서 모호한 면이 있기는 하지만 글의 핵심인 Open Session in View의 사용 여부에만 논의를 집중하는 게 생산적이라고 생각합니다.

그러니 질문하신 내용 중에 이 두 가지는 글의 관심 밖의 문제로 접어 두시는 게 좋을 듯 싶습니다. 2번 사항의 경우, 만약 POJO 원리 주의자의 입장을 고수하시겠다면 Annotation 대신 XML로 ORM 설정했다고 치고 글을 봐도 되겠죠.

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

저는 조영호님의 글을 읽으면서 Open Session In View 설정이 과연 Client 계층에 속하는지 아닌지 생각해보고 있습니다. 조영호님은 클라이언트 계층에 속한다고 보셨고, 그렇지만 다중 계층 아키택처 원칙에 위배 되지 않는다고 하셨습니다. 그런데 저는 오히려 이 부분이 클라이언트 계층에 속한다고 봐야하나 의심스럽습니다. 운영 환경으로 보면 어떨까 싶어요. 다만 제 지식이 입장을 분명히 하기에 부족하네요.

만약, 아직 정립 안 된 제 입장이 어느정도 타당하다면, 최영목님이 제기하신 것처럼 영속성 기술을 ibatis로 바꾸었을 때 (ibatis도 lazy loading이 되니) Open Session in View를 ibatis 방식으로 바꾸거나, Open session in view 설정을 제거해도 클라이언트 계층에 영향을 주는 게 아니라고 볼 수 있지 않을지요.

결국 제가 말하는 가장 중요한 핵심은 과연 화면(view)에서 필요한 데이터를 표현하기 위해서 도메인 자체 또는 도메인의 getter메서드를 노출시키는 것이 옳은 일이냐 하는 것입니다. 물론 실무에서 일을 하다보면 여러가지 사유(특히 일정)때문에 또는 너무 많은 정보 객체의 생성을 회피하기 위해서 도메인 자체를 리턴하는 경우가 굉장히 많습니다.

이건 앞에서 말씀 드린 것 처럼 이 글의 범위를 벗어나는 더 광범위한 논점이므로 따로 토론해야 할 문제 같습니다. 도메인 계층을 클라이언트에까지 공개하느냐 DTO를 쓰느냐는 논쟁은 아직도 계속 되니까요. 제 생각엔 도메인 계층을 공개해도 된다는 쪽으로 기우는 듯 합니다.

하지만 의미론적으로만 접근을 했을 경우 해당 도메인의 정보를 외부에 노출하는 경우 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)의 영향을 많이 받았습니다.

저도 도메인 계층을 공개하자는 쪽과 DTO를 쓰자는 쪽의 절충안 중 좋은 방법이라고 생각합니다.

Application 레이어(또는 Service 레이어)에서 도메인을 리턴한다는 것은 화면(view)에서 어떤 정보를 사용할 지 모른다는 것입니다.

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

도메인이 그래프로 모두 연결돼 있다면 이런 문제가 있죠. 서비스에서는 BbsData 객체를 반환했는데 View에서 이 객체와 연관 관계인 User를 거쳐 Permission 도메인까지 타고 간다면...ㄷㄷㄷ 클라이언트 개발자와 서버 개발자가 분리된 프로젝트라면 우려할만한 상황이고요. 하지만 대부분은 서버 로직을 개발하는 사람이 클라이언트도 개발하니 미리 안티패턴으로 미리 공지하고 주의하도록 한다면 해결 된다고 봅니다.

이를 해결할 수 있는 방법은 2가지라고 생각됩니다.

1. 도메인을 리턴하는 private 메서드를 만들고, 해당 view에서 요구하는 정보 객체를 만들어 인터페이스를 노출시킨다.

2. Hibernate.initialize로 모두 초기화해서 정보를 넘겨준다. (성능문제 발생) : 이는 말씀하신 Open Session in View Pattern을 적용하더라도 ajax통신(json)을 통해 view에서 호출하면

결국 2번과 동일하게 동작하게 됩니다. 정보를 쓰지 않아도 그렇습니다.

위에서 말씀하신 인터페이스 서비스가 도메인 객체 대신 반환하도록 해도 그래프 탐색을 예방할 수 있다고 봅니다.

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

이 부분은 이해가 잘 안 됩니다. TDD를 하면 왜 도메인을 반환하는 일이 생기지 않다고 보시나요? 저희 프로젝트도 TDD를 하지만 도메인을 반환하는데요.

최영목

unread,

Jul 7, 2011, 5:51:38 AM7/7/11

to ks...@googlegroups.com

네. 사실 제 질문이 원래의 글의 요지에서 많이 벗어났습니다. 처음 댓글에서도 마지막에 context를 언급한 이유가

궁금한게 있어서 질문은 하고 싶은데 글의 요지에서는 벗어나고... 어떻게 해야하나... 라고 고민하다가 그냥 결례를 무릅쓰고

물어보자고 생각해서 글을 남겼습니다. ㅠㅠ

그리고 마지막에 "조금 논외이긴 합니다만 정석적인 TDD로 개발을 한다면 도메인을 리턴하는 경우는 없을 것입니다."라고 한 부분은 제가 잘못 생각했네요.

화면부터(jsp 등) TDD로 한다 하더라도 화면에서 보여주는 부분이 도메인구조와 거의 일치하는 경우(예를 들자면 회원정보같은...)에는 도메인을 반환하겠군요 ^^;

왜 글 쓸때는 이 경우를 생각을 못했을까요? ㅠㅠ

앞으로는 좀 더 신중하게 생각하고 글을 써야겠습니다. ㅠㅠ (30대인데도 아직 20대처럼 행동하고 있네요 ㅠㅠ)

2011년 7월 7일 오후 5:29, Sungchul Park <gyu...@gmail.com>님의 말:

--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.

Toby Lee

unread,

Jul 7, 2011, 7:42:32 AM7/7/11

to ks...@googlegroups.com

하이버네이트의 Entity를 DDD의 Entity로 해석하면 무리가 있지 않나 생각됩니다.

하지만 하이버네이트의 Entity의 경우 POJO를 표방하고 있지만 실은 도메인과 영속성이 혼합된 형태의 Entity라고 생각됩니다.

그 예로 Entity임에도 불구하고 애노테이션 형태로 데이터베이스에 의존적인 내용들이 기술되기 때문이죠. 또한 @Transient (JPA 1.0 스펙)을 제공하고 활용한다는 것은 도메인의 원래 목적인 행위를 표현한다기보다는 (특히 데이터베이스)정보를 표현하는 경우로 더 많이 쓰인다는 것이죠.

하이버네이트나 JPA처럼 코드내 애노테이션과 XML을 모두 지원하는 ORM을 사용하는 경우, 기본 원칙은 엔티티의 관계를 기술하는 정보나 엔티티의 고유한 속성을 나타내는 정보는 애노테이션으로 작성하고, 환경에 따라 달라지는 영속성과 관련된 정보(컬럼 내용, 테이블 정보, 인덱스, 키 생성방법 등)은 XML로 작성하는 것입니다.

편의를 위해서 영속 환경에 종속적인 정보를 애노테이션에 담기도 하나, 이는 고속개발이나 프로토타이핑의 경우에 사용하는 변칙일 뿐입니다.

따라서 하이버네이트의 엔티티가 도메인과 영속성이 혼합된 형태라고 단정할 수는 없다고 생각합니다.

최영목

unread,

Jul 7, 2011, 7:56:42 AM7/7/11

to ks...@googlegroups.com

네. 말씀하신 내용을 다시 생각해보니 제 생각이 많이 짧았다는 생각이 듭니다. 알려주셔서 너무 감사합니다. ^^

(사실 스프링3 책은 지금 이 글이 보이는 모니터 바로 옆에 있네요. 항상 참조하고 있습니다. ^^)

두 분 모두 업계 선배님이신데 못난 업계 후배를 위해서 조언을 해주셔서 고마울따름입니다.

그리고 하루 빨리 생각을 성숙시킬 수 있는 자세를 가져야겠습니다. ㅠㅠ

ps. 이번 세미나 때 개인 사정으로 참석하지 못해서 무척 아쉽습니다. 다음에 기회가 생긴다면 고견 부탁드리겠습니다. ^^ (블로그 글 잘 읽고 있습니다.)

2011년 7월 7일 오후 8:42, Toby Lee <toby...@gmail.com>님의 말:

--

박성철

unread,

Jul 7, 2011, 10:46:03 AM7/7/11

to ks...@googlegroups.com

(사실 스프링3 책은 지금 이 글이 보이는 모니터 바로 옆에 있네요. 항상 참조하고 있습니다. ^^)

모니터 받침! (퍽!)

두 분 모두 업계 선배님이신데 못난 업계 후배를 위해서 조언을 해주셔서 고마울따름입니다.

과한 겸손이십니다. 충분히 토론할 만한 주제였다고 생각합니다.

임병인(포데브)

unread,

Jul 7, 2011, 10:01:04 PM7/7/11

to Korea Spring User Group

> 하이버네이트나 JPA처럼 코드내 애노테이션과 XML을 모두 지원하는 ORM을 사용하는 경우, 기본 원칙은 엔티티의 관계를 기술하는 정보나
> 엔티티의 고유한 속성을 나타내는 정보는 애노테이션으로 작성하고, 환경에 따라 달라지는 영속성과 관련된 정보(컬럼 내용, 테이블 정보,
> 인덱스, 키 생성방법 등)은 XML로 작성하는 것입니다.

음 처음 질문과 다른 주제이지만 궁금하여 질문을 드립니다.
위의 내용을 보면 애노테이션과 XML을 동시에 사용하는것같은
생각이 듭니다.
지금까지 JPA로 프로젝트를 하면서 애노테이션만으로 개발하다보니
로직이나 엔티티속성은 변화가 없어도 컬럼의 변화때문에 컴포넌트를
재배포해왔습니다.
토비님이 말씀하신 방법을 지금껏 생각해보지도 못하였기에
두가지를 동시에 사용하는 방법도 현재는 모르고 있습니다.
많은 예제와 문서등이 두가지 방안 즉, 애노테이션과 XML사용에
대해서 설명하고 있지만 애노테이션에서 컬럼을 정의하고
XML에서 관계를 정의하고 있기에 둘중하나를
선택하여 사용하는것으로 오해(?)했었나 싶기도 합니다.
방법 또는 관련자료를 공유할수 있을까요?

Toby Lee

unread,

Jul 8, 2011, 2:26:19 AM7/8/11

to ks...@googlegroups.com

애노테이션과 XML을 함께 사용하는 방법은 JPA 스펙에서 찾으실 수 있습니다.

기본적으로 XML descriptor는 애노테이션 설정을 오버라이드 합니다. 성격에 따라 annotation과 xml에 설정 항목을 잘 분리해서 넣으시면 될 것입니다. JPA 스펙 12장(2.0기준)에 잘 나와있네요.

그 외에도 대부분의 JPA 구현 프레임워크의 레퍼런스 매뉴얼에도 비슷한 설명이 있을 겁니다.

엔티티 관계 정보는 애노테이션에, 퍼시스턴스 정보는 XML에 넣는 것이 바람직하다는 것은 2007년 스프링 원 유럽 컨퍼런스에서 BEA의 EJB 팀 리더이며 OpenJPA 프로젝트의 리더이기도 한 Patrick Linskey의 세션을 통해서 배웠습니다.

상식적으로 생각해도 환경에 종속적이지 않은 순수한 엔티티 정보는 수정시 컴파일이 필요한 애노테이션에 넣고, 환경에 따라 달라지는 퍼시스턴스 정보는 코드 변경 없이 수정 가능한 XML에 넣는 것이 자연스럽습니다. 그래서 JPA 스펙도 XML과 애노테이션을 동시에 사용할 수 있게 했고, 애노테이션 정보에 XML 정보를 추가 또는 오버라이딩해서 활용하도록 만든 것이겠죠.

당시 컨퍼런스 발표자료가 어딘가 있을텐데, 지금은 못찾겠네요. 나중에라도 찾으면 올려드리죠.

JPA 책이나 자료는 따로 본 것은 없지만, 이런 가이드 조차 없다면 좀 실망입니다.

2011/7/8 임병인(포데브) <brianlim...@gmail.com>

Sungchul Park

unread,

Jul 8, 2011, 2:39:53 AM7/8/11

to ks...@googlegroups.com

제가 해보지는 않았고 스펙만 봐서 알고 있기에 답변을 드릴 위치는 아니지만 조금이라도 참고가 될까 싶어 글을 씁니다.

많은 예제와 문서등이 두가지 방안 즉, 애노테이션과 XML사용에
대해서 설명하고 있지만 애노테이션에서 컬럼을 정의하고
XML에서 관계를 정의하고 있기에 둘중하나를
선택하여 사용하는것으로 오해(?)했었나 싶기도 합니다.

아마 대부분의 자료에서 보신 두 가지 매핑 방법은 애노테이션의 경우 JPA 스펙일 것이고 XML은 JPA의 XML(orm.xml)이 아니라 하이버네이트 매핑(hbm.xml)일 겁니다. JPA XML 매핑을 다루는 문서는 흔치 않을 듯 싶네요.

JPA 표준 정의서 12.3장에 XML로 ORM 설정을 하는 규정이 있습니다.

문서에 따르면 이렇게 돼 있습니다.

XML object/relational mapping descriptor is used to selectively override annotation values or whether it serves as a complete alternative to Java language metadata annotations.

그러니까 토비님 말씀처럼 Annotation으로 기본 매핑을 하고 환경에 따라 변화는 부분을 XML로 수정해서 운영할 수도 있고 Annotation을 완전히 대체할 수도 있는 거죠.

검색을 해보니 하이버네이트 쪽 문서에는 annotation 설정을 변경할 수 있다는 정도로만 나와 있습니다.

http://docs.jboss.org/hibernate/entitymanager/3.6/reference/en/html/listeners.html#d0e3102

EclipseLink에는 아주 간단히 언급되어 있네요.

http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Configuration/JPA/orm.xml

만약 하이버네이트 만 쓰신다면 그냥 hbm.xml로 매핑하시는 게 자료도 충분하고 경험자의 도움을 구하기도 쉬울 듯 합니다. 꼭 표준 API를 쓰셔야 한다면 표준 문서 참고해서 시도해보시는 것도 좋겠네요.

최영목

unread,

Jul 8, 2011, 3:08:40 AM7/8/11

to ks...@googlegroups.com

토비님의 글(http://toby.epril.com/?p=341)을 참조로 하여 javaone 2007 자료를 검색해보았습니다.

동영상을 찾을 수 있었습니다.

(http://parleys.com/#st=5&id=146)

이 자료가 맞나요? ^^;;;

2011년 7월 8일 오후 3:39, Sungchul Park <gyu...@gmail.com>님의 말:

Sungchul Park

unread,

Jul 8, 2011, 3:11:05 AM7/8/11

to ks...@googlegroups.com

이런! 가장 좋은 자료를 두고 웹에서만 찾았네요.

이 책... ^^

http://www.aladin.co.kr/shop/wproduct.aspx?ISBN=8992939507

하이버네이트 매핑, JPA Annotation 매핑, JPA XML 매핑을 다 설명하죠.

임병인(포데브)

unread,

Jul 9, 2011, 12:14:21 AM7/9/11

to Korea Spring User Group

빠른 답변 감사드리며 너무 늦게 답글을 달아 미안합니다.

국방대학교에서 다른 연구성 과제를 수행하고 있는데 국방대학교에서는 인터넷이 안되서요.
스마트폰으로 읽기는 했는데 배터리가 다되서 ~~ ^^
후배 직원들에게 스펙을 읽어라 라고 말하면서 저 자신이 스펙에 소홀한 감이 있었네요.
읽어 보기는 했을테지만 읽는 것과 고정관념이 다를 경우 전혀 다른 의미로 받아 들이기도 하는 것 같습니다.

>> 엔티티의 고유한 속성을 나타내는 정보는 애노테이션으로 작성하고, 환경에 따라 달라지는 영속성과 관련된 정보(컬럼 내용, 테이블 정보,
>> 인덱스, 키 생성방법 등)은 XML로 작성하는 것입니다

토비님이 말씀하신 방법이 자연스럽다는 생각입니다.

> 엔티티 관계 정보는 애노테이션에, 퍼시스턴스 정보는 XML에 넣는 것이 바람직하다는 것은 2007년 스프링 원 유럽 컨퍼런스에서 BEA의
> EJB 팀 리더이며 OpenJPA 프로젝트의 리더이기도 한 Patrick Linskey의 세션을 통해서 배웠습니다.

2007년도에 그러한 내용을 접하셨다니 정말 빨랐네요.

이런 토론을 통해서 저의 생각도 많이 넓어지는 것 같습니다.
"이론과 실전"이라는 고전적인 말이 생각납니다. 최근 너무 실전에만 치중해왔다는 생각이 드는 군요.
좋은 정보와 의견 감사합니다.

임병인(포데브)

unread,

Jul 9, 2011, 12:31:57 AM7/9/11

to Korea Spring User Group

JPA 표준을 꼭 준수해야 하는 것은 아니지만
회사의 기술과제중 "GAE와 다른 WAS환경(RDBMS)에 모두 동작가능한 소프트웨어 개발"
이라는 어려운 목표가 있습니다. 어떤 특수한 JPA 구현체의 표준외적인 기능들은 지양하고
가급적 표준내에서 해결하고자 하거든요.
GAE 개발환경에서 동작하는 DataNucleus에서 제공하지 않는 JPA 스펙이 많기도 하구요.

현재는 다른 프로젝트에서 JPA(하이버네이트)를 사용하고 있지만 습관을 들이고 싶어서 표준개발을 선호하고 있습니다.
물론 100% 구현체 종족적인 기능을 사용하지 않는 것은 아닙니다.
Hibernate.initialize() 나 기타 매핑 애노테이션(하이버네이트는 정말 많은 고급기능을 제공하더군요)을 사용하긴
합니다.
하이버네이트를 제거하면 컴파일에러가 ^^

한번 뵈었지만 대부분의 질문자들에게 친절하게 답변을 해주시는 [회장님은 좀짱인듯! ] ^^ ㅎㅎ ㅋㅋ :D ~~~
좋은 정보(다른 구현체 들에 대한 설명까지 친절하게 ...)와 답글에 다시한번 감사드립니다.

Reply all

Reply to author

Forward