Лучшие практики при использовании аннотаций Spring 3

Question

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

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

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

Мой вопрос: что должно входить в аннотации и в какой степени?

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

Answer 1

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

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

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

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

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

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

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

Answer 4

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

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

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

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

Answer 5

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