10
GWT-RPC를 기반으로 현재 서비스 계층을 다른 것으로 마이그레이션하려고합니다. 그것은 각각 5 개의 메소드가있는 약 10 개의 서비스 인터페이스이며 약 20 개의 다른 도메인 엔터티를 포함하므로 모든 것을 변경하는 데 필요한 작업량을 알 수 있습니다. 분명히 최소화하고 싶습니다. 나는 Gilead와 Guice 기반의 중앙 집중식 Servlet을 사용하여 모든 RPC 요청을 처리합니다.RestyGWT 대 RequestFactory
변경의 주된 이유는 다음과 같습니다
- TypeSerializers는 응용 프로그램 코드의 크기의 가장 큰 부분을 소모한다.
- 클라이언트 측 직렬화/직렬화가 특히 GWT-RPC의 일반적인 사실 인 것으로 보이는 dev 모드에서만 느립니다.
- 분명히 온 - 와이어 페이로드를 최소화하고 싶지만 어려운 요구 사항은 아닙니다. 내가 생각하고있어
옵션은 다음과 같습니다 빠른 짐승으로 승진
RequestFactory. 하지만 도메인 객체의 클라이언트 코드에있는 모든 참조를 프록시 프록시로 바꾸려면 많은 작업이 필요할 것이고 실제로 모든 프록시를 빌드하는 것은 게으른 일입니다.
RestyGWT를 사용하여 전체 JSON/REST 접근 방식을 사용하여 도메인 객체를 계속 사용할 수있는 것처럼 보이지만 더 느린 비 직렬화로 끝날 까봐 두려운가요? 나는 어떤 사실을 근거로하지는 않지만 어떤 종류의 벤치 마크도 찾을 수 없었습니다. 그것은 단지 인상입니다.
정말 제안을 받고 싶습니다.
감사합니다.
전체 JSON/REST 방식을 사용하면 다른 클라이언트가 서버와보다 쉽게 상호 작용할 수 있습니다. –
사실이며 JSON/REST를 선호합니다. 하지만 지금은 성능에 대해 더 신경이 쓰입니다. 또한 GWT를 사용하여 모바일 클라이언트를 개발할 계획도하고 있습니다. 먼 미래에 네이티브로 갈 때까지 GWT에서만 작동하는 서비스 레이어가 좋습니다. –
GWT 오버레이 유형을 사용 해본 적이 있습니까? 그들은 (거의 정의에 의해) 매우 낮은 직렬화 비용을 갖는다. – Hbf