[gwt] RequestFactory와 GWT-RPC는 언제 사용해야합니까?

RPC에서 RF로 전환했습니다. 먼저 내 경험이 제한적이라고 말해야합니다. EntityProxies를 0만큼 많이 사용했습니다.

GWT RPC의 장점 :

• 설정, 이해 및 학습이 매우 쉽습니다!
• 클라이언트와 서버에서 동일한 클래스 기반 개체가 사용됩니다.
• 이 접근 방식은 많은 코드를 절약합니다.
• 클라이언트와 서버에서 동일한 모델 객체 (및 POJOS)가 사용되는 경우 POJO == MODEL OBJECTs == DTO
• 서버에서 클라이언트로 물건을 쉽게 옮길 수 있습니다.
• 클라이언트와 서버간에 공통 로직 구현을 쉽게 공유 할 수 있습니다 (다른 로직이 필요할 때 중요한 단점이 될 수 있음).

GWT RPC의 단점 :

• 서버와 클라이언트에 대해 다른 방법을 구현하는 것은 불가능합니다. 예를 들어 클라이언트와 서버에서 다른 로깅 프레임 워크를 사용하거나 다른 equals 방법을 사용해야 할 수 있습니다.
• 더 이상 확장 할 수없는 정말 나쁜 구현 : 대부분의 서버 기능은 RPC 클래스에서 정적 메서드로 구현됩니다. 정말 짜증나.
• 예 : 서버 측 오류 난독 화 추가 불가능
• 우아하게 해결할 수없는 일부 보안 XSS 문제는 문서를 참조하십시오 (RequestFactory에 대해 더 우아한 지 확실하지 않습니다).

RequestFactory의 단점 :

• 공식 문서에서 이해하기가 정말 어렵습니다. 그 장점은 무엇입니까! 그것은 완전히 오해의 소지가있는 용어 PROXIES에서 바로 시작합니다. 이것은 실제로 RF에 의해 자동으로 생성되는 RF의 DTO입니다. 프록시는 인터페이스에 의해 정의됩니다 (예 : @ProxyFor (Journal.class)). IDE는 저널에 해당 메서드가 있는지 확인합니다. 매핑을 위해 너무 많이.
• RF는 클라이언트와 서버의 공통성 측면에서 많은 일을하지 않습니다.
• 클라이언트에서 “PROXIES”를 클라이언트 도메인 개체로 또는 그 반대로 변환해야합니다. 이것은 완전히 우스꽝 스럽습니다. 몇 줄의 코드로 선언적으로 수행 할 수 있지만 이에 대한 지원은 없습니다! 도메인 객체를 프록시에 더 우아하게 매핑 할 수만 있다면 JavaScript 메소드 JSON.stringify (.. ,,)와 같은 것이 RF 도구 상자에서 MISSING입니다.
• 도메인 개체의 양도 가능한 속성을 프록시 등으로 설정하는 것도 재귀 적으로 담당한다는 사실을 잊지 마십시오.
• 서버에서 불량한 오류 처리 및-스택 추적은 기본적으로 서버에서 생략되고 클라이언트에서 쓸모없는 빈 예외가 발생합니다. 사용자 지정 오류 처리기를 설정해도 저수준 스택 추적에 도달 할 수 없었습니다! 무서운.
• IDE 지원 및 다른 곳의 사소한 버그. 나는 두 개의 버그 요청을 접수했습니다. 그것들이 실제로 버그라는 것을 알아 내기 위해 아인슈타인이 필요하지 않았습니다.
• 문서가 짜증나. 내가 언급했듯이 프록시는 더 잘 설명되어야하므로 용어는 잘못된 것입니다. 내가 해결하고 있던 기본적인 공통 문제에 대해서는 DOCS가 유용합니다. DOC에서 오해의 또 다른 예는 JPA 주석을 RF에 연결하는 것입니다. 간결한 문서에서 그들이 함께 플레이하는 것으로 보이며 예, StackOverflow에 해당하는 질문이 있습니다. RF를 이해하기 전에 JPA ‘연결’을 잊어 버리는 것이 좋습니다.

RequestFactory의 장점

• 우수한 포럼 지원.
• IDE 지원은 매우 우수합니다 (그러나 RPC와 달리 이점은 아님).
• 클라이언트 및 서버 구현의 유연성 (느슨한 결합)
• 단순한 DTO를 넘어 EntityProxies에 연결된 멋진 것들-캐싱, 부분 업데이트, 모바일에 매우 유용합니다.
• ValueProxies를 DTO의 가장 간단한 대체물로 사용할 수 있습니다 (하지만 모든 멋진 변환을 직접 수행해야하는 것은 아닙니다).
• Bean 유효성 검사 JSR-303 지원.

일반적으로 GWT의 다른 단점을 고려합니다.

• 제공된 JUnit 지원으로 통합 테스트 (GWT 클라이언트 코드 + 원격 서버)를 실행할 수 없습니다. <= 모든 JSNI가 모의 처리되어야합니다 (예 : localStorage). SOP가 문제입니다.

• 테스트 설정 지원 없음-헤드리스 브라우저 + 원격 서버 <= GWT, SOP에 대한 간단한 헤드리스 테스트 없음.

• 예, 셀레늄 통합 테스트를 실행할 수 있습니다 (하지만 제가 원하는 것은 아닙니다).

• JSNI는 매우 강력하지만 회의에서 발표하는 반짝이는 강연에서는 JSNI 코드 작성에 몇 가지 규칙이 있다는 것에 대해 많이 이야기하지 않습니다. 다시 말하지만, 간단한 콜백을 작성하는 방법을 알아내는 것은 진정한 연구자의 가치가있는 작업이었습니다.

요약하면, GWT RPC에서 RequestFactory 로의 전환은 RPC가 대부분 사용자의 요구에 맞는 WIN-WIN 상황과는 거리가 멀습니다. 결국 클라이언트 도메인 개체에서 프록시로 또는 그 반대로 많은 변환을 작성합니다. 그러나 솔루션의 유연성과 견고성을 얻을 수 있습니다. 그리고 포럼에 대한 지원은 토요일에도 훌륭합니다!

방금 언급 한 모든 장단점을 고려할 때 이러한 접근 방식이 실제로 큰 절충없이 솔루션과 개발 설정을 개선 할 수 있는지 여부를 미리 생각하는 것이 좋습니다.