В чем преимущество наличия компонентов создания экземпляров Джерси

Все образцы кода Spring Boot и Jersey, которые я видел, регистрируют свои компоненты с помощью Jersey, передавая класс компонента.

Из здесь:

  public static class JerseyServletConfig extends ResourceConfig {
    public JerseyServletConfig() {
      register(RequestContextFilter.class);
      packages("com.github.cthiebault");
      register(LoggingFilter.class);
    }
  }

Или здесь:

register(ApiListingResource.class);

Javadoc ResourceConfig говорит:

Зарегистрируйте экземпляр пользовательского компонента JAX-RS (например, поставщика расширений или метапоставщика функций), который будет создан и использован в рамках этого настраиваемого контекста.

Мои вопросы:

  1. В чем преимущество создания экземпляров этих ресурсов на Джерси?

  2. Если мы должны позволить Джерси управлять этими компонентами, почему он по-прежнему предоставляет метод register(Object component), почему бы не ограничить его register(Class<?> componentClass)?

  3. Когда мы должны отправлять свои собственные экземпляры вместо того, чтобы позволять Джерси создавать экземпляры нашего класса?


spring-boot java jax-rs jersey jersey-2.0
person user384729    schedule 22.02.2016    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Начнем с того, что внедрение зависимостей в целом является хорошей вещью (tm) — оно позволяет разделять проблемы и может значительно упростить тестирование. В общем, отделение создания объекта от использования объекта дает преимущества, связанные с отделением логики бизнеса/приложения (т. е. использования объекта) от проблем реализации (решения, какие объекты связаны друг с другом).

Разрешение Джерси управлять вашими ресурсами/компонентами также является хорошей вещью (тм). Это часть того, для чего предназначен Джерси. Если вы разрешите Джерси управлять жизненным циклом вашего ресурса, у вас будет меньше кода для написания/сопровождения, а код, который вы делаете в конечном итоге пишете/сопровождаете, больше зависит от того, что ваше приложение делает и меньше о том, как ваши объекты сочетаются друг с другом.

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

Метод register(Object) является примером того, как вы можете отказаться от Джерси, контролирующего жизненный цикл компонента. Вы можете захотеть сделать это по многим причинам, но обычно вам следует избегать этого - пусть библиотека делает свою работу. Примерами исключительных случаев могут быть, если вы интегрируете какой-либо устаревший код, который по неясным/тайным причинам сам по себе означает, что некоторый критический класс должен быть синглтоном на уровне приложения. Могут быть даже некоторые нетрадиционные причины, по которым вам нужен только один экземпляр чего-либо в вашем приложении — сопоставители объектов всегда были хорошим примером этого. Как правило, в настоящее время для этого используется поддержка JSR-330, но могут быть случаи, когда это невозможно.

Интегрируясь с JSR-330, вы также можете предоставлять настраиваемые именованные области для некоторых объектов, что позволяет вам контролировать, как Джерси создает и использует объекты, а также раскрывать то, что вы намереваетесь (через имя области). Как правило, это обеспечивает чистую структуру, которая раскрывает, а не скрывает намерение.

person sisyphus    schedule 23.02.2016