GWT RequestFactory 및 클라이언트 측 서버 측 변경 사항 전파

Question

GWT의 RequestFactory를 사용하여 서버 측 클라이언트 변경 사항을 클라이언트에 전파하는 것이 가장 잘 처리되는 방법에 대한 조언이 필요합니다.

두 개의 EntityProxies, PersonProxy 및 PersonListProxy (List에 대한 getter가 있음)가 있다고 가정합니다. 클라이언트가 서버에서 PersonList와 Person을 가져왔다 고 가정합니다.

클라이언트가 이러한 프록시 중 하나를 편집하고 요청을 실행하는 경우 RequestFactory의 기계는 서버 코드에 의해 수행 된 변경 사항을 감지하면 EntityProxyChange 이벤트를 발생시킵니다 (클라이언트가 예를 들어 엔티티의 표시를 업데이트 할 수 있습니다.

이제이 클라이언트가 Person 또는 PersonList를 다시 가져온 경우이 클라이언트가 다른 버전을 볼 수 있도록 서버가이 클라이언트의 요청을 벗어나는 엔티티를 변경한다고 가정합니다 (예 : 서버를 호출하는 다른 클라이언트로 인해).

제 질문은 RequestFactory 프레임 워크에서 클라이언트에게 변경 사항을 알려주고 (가능한 한 많은 기계류를 재사용하는) 가장 좋은 방법은 무엇입니까? 서버에서 클라이언트로 간단한 메시지 (예 : Google App Engine의 채널 API 또는 서버 전송 이벤트)를 보낼 수있는 방법이 있다고 가정합니다.

한 가지 아이디어는 서버가이 채널을 통해 특정 ID가있는 Person 또는 PersonList가 변경되었다는 메시지를 보내는 것입니다. 이들 메시지의 수신을 처리하는 클라이언트 코드는 RequestFactory를 사용하여 엔티티를 다시 패치 (예를 들면 발견) 할 수있다. 이 변경 사항은 EntityProxyChange 이벤트에 의해 클라이언트의 다른 부분에 전파되어야합니다.

이 방법이 있습니까? (그리고 클라이언트가 이미 엔터티의 현재 버전을 가지고있는 경우 (예 : 서버가 바보 상태 였고 클라이언트가 변경 한 사항을 클라이언트에게 알린 경우) 트리거 된 다시 불러 오기는 전체 메타 데이터가 아니라 약간의 메타 데이터 만 전송합니다. 엔티티 다시)

ADDED : 그것에 대해 좀 더 생각

, 나는 EntityProxyId 년대는 서버 전송 이벤트 채널에 대해 생성 될 수 있는지 궁금합니다. 서버의 엔티티가 변경되면 서버는 서버 ID 만 갖습니다. 물론 클라이언트에게 보낼 수는 있지만 클라이언트는 EntityProxyId 만 알고 있습니다. 물론 각 EntityProxy에 getId() (getStableId()에 추가)를 추가 할 수는 있지만 모든 서버 응답에 중복 데이터가 추가되는 것처럼 보입니다.

Answer 1

글쎄, 내 글은 당신의 질문에 대한 정확한 답변이 아니라는 것을 알지만, 그것은 나의 경험 일뿐입니다. 사실 서버에서 클라이언트로 데이터를 전달하는 방법에 대한 질문 만 있습니다. 몇 년 전에 몇 가지 작업에 직면하고 내 인생을 더 쉽게 만들어주는 접근 방식을 찾았습니다.이를 설명하기 위해 이유를 설명하고자합니다 :

• 클라이언트로부터 요청하면 전체 데이터를 제공해야합니다. 데이터를 요청하는 것은 자연스럽고 자연스러운 방법입니다.
• 두 가지 모델의 전체 데이터 전달을 작성하고 지원하고 싶지 않습니다. 하나는 클라이언트에서 요청하고 다른 하나는 서버에서 푸시하여 데이터를 전송합니다.
• 하지만 서버 측에서 변경 사항에 대해 클라이언트에게 알릴 필요가 있습니다. 그래서

, 지금은 다음과 같은 방식 사용하여 내 아키텍처를 짓고 있어요 :

1. 데이터 전송에 대한 완전한 고전 클라이언트 - 서버 API를 빌드 -로드하고 자연적인 방법 경우에도에서 응용 프로그램을 새로 고칠 수 있도록 당신의 푸시 기능이 차단되거나 파손되었습니다.
2. 서버 측에서 변경할 수있는 키 정보를 정의하고 푸시 메커니즘을 통해 클라이언트에 전달해야합니다.
3. 변경 사항에 대해 에 대한 알림 ()을 전달하는 작은 푸시 메시지 구조를 생성하십시오. 어떤 방법으로도 중요한 데이터가 전달되지 않아야합니다. - 데이터가 변경된 키.
4. 이러한 알림을받을 때 클라이언트에서 수행해야하는 모든 작업은 이미 지원되는 자연 클라이언트 - 서버 방식으로 서버에서 데이터를 가져 오거나 새로 고치는 것입니다.
5. 서버 로직은 막대한 양의 알림으로 클라이언트 측을 괴롭히지 않아야합니다. 때로는 변경 사항을 전달하지 않고 모든 것을 새로 고치는 것보다 효과적입니다.

희망이 도움이됩니다.