Сериализация GWT не должна возвращать интерфейсы: как насчет параметров и содержащихся объектов?

Уже есть несколько вопросов относительно того факта, что методы в GWT RPC должны не возвращать интерфейс, подобный List, а скорее конкретный класс, такой как ArrayList, потому что в противном случае «GWT должен включать все возможные реализации». См., Например, Почему в GWT метод не должен возвращать интерфейс? < / а>

Вот мой вопрос: ограничивается ли это самим возвращаемым типом? Как насчет параметров метода? А что, если возвращаемый объект содержит интерфейс, например

public class MyReturnObject implements IsSerializable {
   List<String> listOfUnspecifiedType1;
   List<Long> listOfUnspecifiedType2;
   ...
}

Все примеры, которые я видел, говорят о самом возвращаемом типе. Я не понимаю, почему было бы проблемой вернуть интерфейс, но не проблемой вернуть объект, который просто обертывает интерфейс; но, может быть, я что-то упускаю?


gwt gwt-rpc
person user711413    schedule 15.01.2013    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Из связанного вопроса ясно, что он применяется рекурсивно (и как только вы поймете, почему вы должны использовать как можно больше производных типов, становится очевидным, что это рекурсивно).

Это также верно для аргументов метода, а не только для возвращаемых типов и их полей: если вы отправляете List<X>, то GWT должен сгенерировать код сериализации для всех List классов: ArrayList, LinkedList и т. Д.

И, конечно же, то же самое относится к классам, а не только к интерфейсам: AbstractList ничем не отличается от List.

А поскольку генерация происходит до оптимизации, будут включены все возможные классы из исходного пути, а не только те, которые вы используете в своем коде; а затем они встают на пути этапа оптимизации, поскольку все эти классы сейчас используются вашим приложением.

Поэтому правило таково: по возможности используйте наиболее конкретные типы. Вывод: не бойтесь DTO, не пытайтесь любой ценой отправлять объекты своей компании / домена.

person Thomas Broyer    schedule 15.01.2013
comment
Спасибо ... В этом есть смысл, я просто хотел убедиться. - person user711413; 17.01.2013