2011-08-12 4 views
1

저는 JPA에 익숙하지 않지만이 시나리오를 가지고 있습니다 : KISS/DRY 이유로 서버와 클라이언트 (Java SE) 모두에서 동일한 클래스 ("코드"읽기)를 사용하고 싶습니다. 나에게 이것이 한 가지 가능한 방법은 엔터티에 대한 요청을 서버에 전달하고 마지막 엔 "배치 지속 작업"을 위해 모든 엔티티를 다시 서버로 전달하는 클라이언트에 (특수한) EntityManager을 갖는 것일 것입니다. 클래스가 데이터의 유효성을 재확인하고, JPA 구현으로 일부 트랜잭션 작업 (업데이트 및 내용)을 적용하고 모든 것을 잘 유지할 수있는 곳.원격으로 관리되는 엔티티를 가질 수 있습니까?

질문은 : 가능합니까? 방법? (? 간단, 종류의 "일부"코드로이 문제를 해결하기 위해위한 솔루션입니다 이미입니까?)


편집 : 좋아, 내가 모든 사람들을위한 몇 가지를 명확히하자. 내 배경은 일반적인 퍼시스턴스 서비스라고 할 수있는 것을 사용하는 사내에서 성장한 애플리케이션 프레임 워크입니다. 즉 하나의 트랜잭션 내에서 CRUD 작업 (모든 테이블에 대해 하나의 작업 당 하나의 서비스)을 수행하지만 이러한 작업을 가로 채고 유효성 검사 및 복잡한 비즈니스 규칙 (다른 테이블, 기타.). 이는 구형 Microsoft 제품으로 구현되었습니다. DevForce 및 CSLA와 같이 최근에 유사하게 작동하지만 고급 프레임 워크가 등장한 .NET으로의 전환이있었습니다. DevForce는 특히 Java에서 수행하고자하는 것을 제공합니다 (클라이언트에서 실행하기 "this page에있는 문단을 참조한 다음 더 나은 개요를 보려면 this page을 방문하십시오).

이 일반적인 주제에 내 이전 질문 : Java "equivalent" to CSLA

+1

그리고 분리 된 엔티티를 클라이언트로 전송하고 수정 한 다음 다시 첨부하여 서버에 다시 첨부하여 지속성을 유지하는 것과 어떻게 다른가요? –

+0

@edalorzo 그건 내가 말하는거야,하지만 ... "경영"이 핵심 단어. 클래스가 JPA를 사용할 수 있기 때문에 클라이언트에서 EntityManager를 사용하여 내가 작업했던 모든 엔티티를 "묶어서"팩키지하게 만들 수는 없을까? 하나의 트랜잭션 스누핑 (transactional swoop)에서 영속성을 제대로 처리 할 수있는 서버상의 EntityManager? – Doc

+0

아직 귀하의 시나리오를 이해하고 있다고 생각하지 않습니다. 내 관점에서 볼 때 클라이언트는 엔티티 관리자와 같은 것이 존재하는지조차 알 수 없습니다. 비즈니스 인터페이스를 통해 정확하게 노출 된 서버는 클라이언트가 요청할 때 단일 트랜잭션 급습에서 제안한 모든 작업을 수행 할 수 있으며 엔티티는 서버의 안전을 포기하지도 않습니다. 동시성에 관해서는 클라이언트 당 지속성 컨텍스트를 갖는 것이 악몽입니다. 동시성의 수준에 따라 모든 클라이언트는 매우 짧은 시간에 부실 캐시가 될 수 있습니다. 생각하지 않니? –

답변

0

당신의 생각은 똑똑하다.

하지만 제안한 것을 할 수는 없습니다. 왜 안 그래? 음, 이것을 대답하기 위해서는 우선 "관리 대상이 무엇인지"를 이해해야합니다.

관리되는 엔터티는 "캐시 된"인스턴스 외의 것입니다. 엔티티 관리자 내부에있는 인스턴스입니다. 네트워크를 통해이 인스턴스를 다른 시스템에 보내면이 인스턴스를 직렬화합니다. 따라서 복사 : 원격 서버에 다른 인스턴스 생성 (물론 엔티티 관리자가 해당 인스턴스에 대해 알지 못하기 때문에) 존재).

반대편 엔티티 관리자를 시뮬레이트하고이 복사 된 엔터티를 trasparently "관리"할 수있는 "스마트 한"것이있을 수 있지만 JPA 사양을 벗어나기 때문에 직접 구현해야합니다. 쉬운 일이 아닌 것처럼 보입니다.) 나는 거기에 믿을만한 어떤 것도 존재하지 않는다고 생각합니다.

귀하의 솔루션은 서버에서 노출 된 메소드를 통해 클라이언트로부터 명시 적으로 유지, 업데이트 등을하는 것입니다.

+0

즉, 서버의 EntityManager의 중요한 메소드를 클라이언트에 공개해야합니까? 거래는 어쩌고 요? 나는 트랜잭션을 직접 제어해야한다는 예제를 보았다. 트랜잭션을 시작하고, 내 일을 처리 한 다음, 트랜잭션을 커밋한다. 필자는 내 일을하고 싶습니다. 그리고 EntityManager에게 트랜잭션 내에서 영속성을 위해 필요한 모든 것을 자동으로하도록 말하고 싶습니다. – Doc

+0

이 작업을 수행하는 방법은 1 트랜잭션에서 실행되는 서버에서 "비즈니스 서비스"(예 : placeBid)를 노출하고 사용자의 "화면 흐름"이 완료되면 호출합니다. 클라이언트로부터 열린 트랜잭션을 유지하기 위해서 (따라서 가능하다) 보통 좋은 생각이 아니다. 여러 서비스 호출에 걸친 클라이언트에서 열린 트랜잭션을 유지 관리 할 수는 있지만 해결 방법없이 네트워크를 통해 전송 될 때 엔티티는 항상 분리됩니다. – edutesoy

1

내가

(I는 WS 동안 그 시간을 최대 절전 모드 +있는 XFire를 사용했다) 전에 비슷한 일을 시도하고 어쩌면 그냥 내 연구 결과에 비트를 공유 한 나는 당신이 이론적으로 작품을 생각하고 무엇을 생각합니다. 필요한 것은 관리 대상 엔티티를 직렬화하여 클라이언트에게 전송하는 것입니다. 클라이언트는 객체를 비 직렬화하고 업데이트합니다 (물론 클라이언트 측에서 관리되는 엔티티가 아닌 일반 POJO입니다). 이 시점에서 서버에 의해 수신 된 객체는 분리 된 객체 일뿐입니다. 세션에 다시 접속할 수 있습니다 (JPA/Hibernate는 당신을 위해 낙관적 동시성 검사를 할 것입니다).

그러나 POJO는 매우 간단하게 작동합니다.가장 큰 문제점 중 하나는 JPA (또는 대부분 모든 ORM 프레임 워크)에서 서로 다른 엔티티 사이의 관계를 유지하는 것입니다. 예를 들어 주문은 제품 및 계정과의 관계를 가지며 계정은 클라이언트와의 관계를 갖게되고 클라이언트는 주소 목록을 갖게됩니다 .... 등등. 게으른 인출, 관계 때문에 서버 측에서 조작하는 경우 대부분 괜찮습니다 당신이 그것을 액세스 할 때까지 실제로 가져 오지 않습니다. 그러나 직렬화를 수행하면 해결하기 어려운 문제가됩니다. JAXB와 같은 대부분의 직렬화 솔루션은 모든 속성을 재귀 적으로 탐색합니다. 결과적으로 Order 객체 만 클라이언트 측에 보내지 만 마침내 거대한 데이터를 Client에 보냅니다. 단순히 어떤 속성을 직렬화하지 말라고 시리얼 라이저에게 알려주지 않는다면, 객체가 되돌려 보내 졌을 때 분리 된 obj를 다시 세션에 연결하면 JPA/Hibernate는 단순히 관계를 무시하거나 실제로 관계를 제거합니다. 물론 당신이 할 수있는 몇 가지 속임수가 있지만 이러한 모든 접근법은 고통스럽게 받아 들여지고 더 이상 우아하지 않습니다.

+0

공유해 주셔서 감사합니다. – Doc

관련 문제