2010-01-13 8 views
3

Если метод приложения JAX-RS вернет объект домена, представление (например, JSON) будет содержать все атрибуты этого объекта - правильно? Но что, если этот объект будет содержать «частные» данные, которые не должны подвергаться воздействию Интернета?Требуется ли JAX-RS объекты передачи данных (DTO)?

А что такое другое направление извне в: как можно предотвратить, чтобы частные поля были переопределены?

Единственным решением для этого является создание объектов передачи данных (dto).

Использовать «automapper» не было бы решением, если не указать, какие поля следует отображать.

Итак, заставляет разработчиков JAX-RS создавать DTO? Или есть другое решение?

ответ

1

@XmlTransient (или соответствующая аннотация) инструктирует mappers/marshallers не включать аннотированное свойство в сериализованном выходе.

+0

Спасибо, это то, что я находясь в поиске. – deamon

3

Для прозрачной сортировки и демонстрации XML-данных вашего объекта аннотировать его с помощью аннотаций JAXB (класс может быть аннотирован с аннотациями JPA и JAXB и, таким образом, предоставлять представление XML, а также сохраняться в база данных).

@Entity 
@XmlRootElement 
public class MyEntity implements Serializable { 

    @Id @GeneratedValue 
    private Long id; 

    .... 

} 

В приведенном выше примере я использую только один JAXB аннотации @XmlRootElement. Теперь предположим, что вам не нужно свойство id в сериализованном XML. Просто добавьте JAXB аннотацию @XmlTransient к нему:

@Entity 
@XmlRootElement 
public class MyEntity implements Serializable { 

    @XmlTransient 
    @Id @GeneratedValue 
    private Long id; 

    .... 

} 

Таким образом, нет, нет строгой необходимости DTOS (и шаблонный код для отображения их и от юридических лиц).

+0

Whow! Очень круто! – deamon

+0

Работает ли @XmlTransient с каждым форматом вывода JAX-RS или ограничивается XML и JSON? – deamon

+0

@XmlTransient от JAXB, JAXB для XML. Выходы JSON поддерживают подмножество. Так что это зависит от сериализатора, используемого для рассматриваемого формата. FWIW, я не знаю других «стандартных» сериализаторов, поэтому это может быть спорным вопросом. – StaxMan

2

Я думаю, что лучше сказать, что JAX-RS требует, чтобы вы использовали изображений.

Объект домена My Foo не имеет представления, что он используется в RESTful способом. Он знает только о Bar (другой корень заполнителя) и любых объектах, с которыми он может перемещаться через эту панель. На самом деле, у меня также есть интерфейс командной строки для этого приложения, которое не использует REST или даже HTTP.

Интерфейс моего RESTful обертывает Foo/Bar в представления, которые ссылаются друг на друга через URI. Я думаю, вы можете называть эти DTO, но если вы (как указано в других ответах) просто аннотируете свою модель домена с тем, что требуется для маршала и их развязывания, я думаю, что вы кодируете себя в угол, который запрещает HATEOAS.

Это также очевидно, когда у вас есть коллекция. Если Foo -> * Bar, вы собираетесь вернуть все элементы Bar в своей немаршаллированной форме? Почему не только URI и, возможно, некоторые другие минимальные данные, , например.

GET Foo/FFF

<foo> 
    <link rel="self" uri="uri="foo/fff" /> 
    <bar uri="bar/abc123"> 
    <status="Active" /> 
    </bar> 
    <bar uri="bar/qqq"> 
    <status="Inactive" /> 
    </bar> 
</foo> 

Если клиент хочет узнать больше о данном баре, он может

GET бар/абв123

<bar> 
    <link rel="self" uri="bar/abc123" /> 
    <foo uri="foo/fff" /> 
    <status>Active</status> 
    <title>Some Bar</title> 
    ... 
</bar> 
+0

Конечно, это только начало, потому что с HATEOAS вы будете предоставлять другие ссылки, которые «означают» то, на что может воздействовать клиент, и именно здесь важно помнить, что URI непрозрачны и не имеют укажите документ. Например, для bar/abc123 вы можете отправить его на бар/деактивировать URI и установить статус неактивным. Или общий деактивировать URI - или что угодно! Смысл заключается в гипертексте и отношениях, которые вы определяете. Вы * не * должны просто проходить мимо DTO. –

+1

Недостатком является то, что использование этих * классов представления означает весь другой набор объектов для поддержки. Я видел людей, которые использовали класс Resource для представления «быть». Может быть, это лучший выбор, но мне показалось, что он забит. Моя единственная догадка заключается в том, что мне нужно еще больше логично подключиться к службам и объектам домена и не использовать их из ресурса, но я избегал этого, потому что я действительно не хочу, чтобы домен знал, что его используется в RESTful способом. –