App Engine - RequestFactory vs servlets và các aproaches khác

Question

Nhóm của chúng tôi đang làm việc trên Ứng dụng Android đã kết thúc với App Engine. Chúng tôi có một số khác biệt về ý kiến ​​liên quan đến việc thực hiện giao tiếp giữa khách hàng và máy chủ. Một mặt App Engine cho thấy cách tiếp cận RequestFactory, trong đó (như Google nói)

provides a solid foundation for automatic batching and caching of requests in the future

và light-weighed

Nhưng chúng ta tìm cách tiếp cận này một chút "vụng về". Mặt khác, chúng ta có thể sử dụng một cách tiếp cận servlet thông thường mà chúng ta biết rõ, và cảm thấy thoải mái hơn. Chúng tôi chắc chắn muốn bật lửa, nhanh hơn và khả năng mở rộng mới thông tin liên lạc, nhưng tỷ lệ nào RequestFactory thực sự cung cấp cho họ? Chúng ta có thể đạt được gì nhiều hơn và mất đi từ cả hai cách tiếp cận.

[Thêm vào đó, chúng tôi đọc về các tùy chọn như GWT-RPC (phiên bản cũ hơn của RequestFactory) và RestyGWT. Nhưng chúng tôi biết rất ít về những cách tiếp cận này và không chắc liệu chúng có phù hợp với trường hợp của chúng tôi hay không.]

Tôi tìm thấy ở đây một số câu hỏi tương tự chưa được trả lời. Vì vậy, tôi cho rằng, đây có thể là một cuộc thảo luận hữu ích cho nhiều người.

Answer 1

Một vài lưu ý:

1. RequestFactory không phải là một phần của AppEngine (xem here), nhưng một add-on được giới thiệu bởi các plugin mới nhất Android Eclipse. Ban đầu RequestFactory đã được tạo cho GWT.

2. Ưu điểm của RequestFactory là hoạt động liền mạch với GWT và Android.

3. Nhược điểm là nó không phải cross-platform, ví dụ: không có sẵn cho iPhone, vv ..

4. Đó là chưa rõ làm thế nào để phiên bản RequestFactory. Nếu ứng dụng của bạn lớn và phát triển, bạn nhất định có hai hoặc nhiều phiên bản của API RPC phục vụ khách hàng. Khách hàng GWT có thể dễ dàng bị buộc phải sử dụng API mới nhất (= tải lại trang), không phải như vậy với Android. AFAIK, không có tùy chọn có hai điểm cuối RequestFactory. Với REST, bạn chỉ có thể có nhiều URL cho các phiên bản API khác nhau.

5. Trộn API công khai/riêng tư. Vì không có nhiều điểm cuối RequestFactory, bạn không thể dễ dàng chia chúng thành công khai (không yêu cầu auth) và riêng tư/an toàn (= auth required). Với REST (và GWT-RPC), bạn có thể chỉ đơn giản có hai servlet (private và public) và thiết lập các ràng buộc bảo mật trong web.xml (hoặc có bộ lọc servlet của riêng bạn).

6. RequestFactory không hỗ trợ java.util.Map. Điều này hạn chế bạn có khả năng có các thực thể với các thuộc tính động - có cách giải quyết cho điều này nhưng chúng là IMO một kludge không cần thiết (như có hai danh sách, một cho các khóa khác cho các giá trị).

Giải pháp: đây là một giải pháp mà tôi sử dụng trong các dự án của tôi:

1. Tạo một lớp dịch vụ trả về đối tượng miền POJO.

2. Tạo lớp RPC gọi lớp dịch vụ. Bạn có thể có nhiều công nghệ RPC gọi cùng một lớp dịch vụ. Tôi thường có GWT-RPC và REST.

3. Sử dụng các đối tượng miền chỉ POJO đôi khi không thể (cũng do JPA/JDO), do đó buộc bạn phải tạo DTO. DTO là một nỗi đau để duy trì và tôi cố gắng tránh chúng nếu có thể. Có thể sử dụng các đối tượng miền hầu hết thời gian với một số cách giải quyết: trên AppEngine, bạn có thể nhận được rất nhiều trợ giúp bằng cách sử dụng Objectify thay vì cấp thấp/JPA/JDO. Nó supports GWT-RPC. Với REST tôi đề nghị bạn sử dụng Jackson nơi bạn can do all kinds of custom conversions.