Рекомендации по использованию Spring 3 аннотаций

Я ищу некоторые рекомендации при использовании Spring 3 аннотаций.

В настоящее время я перехожу к Spring 3 и из того, что я прочитал до сих пор, я вижу много акцентов на использование аннотаций и переход от конфигурации XML.

На самом деле рекомендуется использовать сочетание обоих стилей с аннотациями, которые охватывают вещи, которые не будут меняться часто или от одного прогона к другому (например, @Controller останется таким же, как и в течение срока службы приложения) в то время как вещи, которые изменяются и должны быть настроены, переходят в XML (например, адрес SMTP-почты, конечные точки для веб-сервисов, к которым ваше приложение говорит и т.д.).

Мой вопрос заключается в том, что должно идти в аннотации и в какой степени?

В какой момент аннотации делают вещи сложнее, а не проще? Является ли технология (Spring 3) полностью принятой, чтобы иметь возможность делать такие заявления или требуется больше времени для людей, чтобы получить опыт работы с ней, а затем подумать над этой проблемой?

Ответы

Ответ 1

Всегда сложно получить реальную расширенную информацию.

Простой учебник с "взглянем на мой блог, я скопировал учебник по приветственным слоям из веб-сайта Spring Source... Теперь вы можете поместить фантастические аннотации повсюду, это решение всех наших проблем, включая рак и голод". не очень полезно.

Если вы помните, что у правильного ядра Spring было несколько целей, среди них:

  • быть неинтрузивным
  • изменить любой реализации/конфигурации bean в любое время
  • предоставить централизованный и контролируемый место для размещения вашей конфигурации

Ошибка анотации для всех потребностей:

  • Они вводят связь с spring (вы можете использовать только стандартную анотацию но как только у вас есть хотя бы один spring anotation это уже не правда)
  • Вам необходимо изменить исходный код и перекомпилировать для изменения bean реализации или конфигурации
  • Аннотации повсюду в вашем код. Это может быть трудно найти что bean будет действительно использоваться только чтение кода или конфигурации XML файл.

Фактически мы сместили наш фокус:

  • Мы поняли, что почти никогда обеспечивают несколько реализаций наши услуги.
  • Мы поняли, что зависимость от API не так уж плох.
  • Мы поняли, что мы используем Spring не только для реальной инъекции зависимостей больше, но в основном для увеличения производительность и сокращение Java-кода многословие.

Таким образом, я бы использовал анотации, когда делал это. Когда чище удалить код шаблона, многословие. Я бы позаботился о том, чтобы использовать файл конфигурации XML для того, что вы хотите настроить, даже если он предназначен только для обеспечения реализации службы в модульных тестах.

Ответ 2

Я использую @Value для свойств, которые настроены во внешнем файле свойств через PropertyPlaceholderConfigurer, как отметил kunal.

Нет строгой строки для использования xml, но я использую xml:

  • когда bean не относится к классу I
  • когда объект связан с инфраструктурой или конфигурацией, а не с бизнес-логикой.
  • когда класс имеет некоторые примитивные свойства, которые я хотел бы настраивать, но не обязательно через внешние конфигурации.

В ответ на ваш комментарий: spring очень широко принят, но "хорошие" и "плохие" очень субъективны. Даже мои строки не являются универсальными истинами. XML, аннотации и программная конфигурация существуют для определенной цели, и у каждого разработчика/компании есть свои предпочтения.

Как я уже сказал - нет строгой линии и универсальной хорошей практики для аннотаций.

Ответ 3

Аннотации - это, конечно, способ, которым будет продолжаться "новое" программирование в java. Я использую аннотации для различных применений... например @Scope для области bean, @Required для обеспечения необходимой зависимости, @Aspect для настройки советов, @Autowired для встраивания конструктора с помощью аннотаций. Поскольку spring 2.5, поддержка аннотации была хорошей. См. Здесь spring учебник, в котором рассмотрена проблема с аннотацией здесь.

Ответ 4

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

Вторая проблема - переносимость версий JVM. Аннотация - это функция 1.5+. Если ваше программное обеспечение должно поддерживать более ранние версии JVM, вы можете не использовать их.

В любом случае, вы можете наслаждаться аннотациями каждый раз без каких-либо сомнений и не тратить свое время, не меняя вкладки IDE, чтобы проверять XML файлы, если свойство все еще там или нет, или введены правильно и т.д.

Для очень маленьких проектов вы все еще можете использовать XML-версию, если в spring не указано слишком много материалов. Но если вы находитесь в огромном проекте, все может быть очень неприятным, если у вас есть 10 xml-конфигураций.

Ответ 5

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