Весенние аннотации противоречат моим рекомендациям по дизайну - PullRequest
Новая
       18

Весенние аннотации противоречат моим рекомендациям по дизайну

4 голосов
/ 30 ноября 2010

Обзор
Использование

  • Spring 3.0.1 (конфигурация аннотации)
    • Текущая конфигурация использует CGLib в качестве создателя прокси, но это не моепредпочтение
    • Транзакции - это аннотации, настроенные без каких-либо специальных настроек
    • Все настройки выполняются с аннотациями (@Service, @Transactional, @ManagedResource, @Inject и т. д.)
  • Hibernate 3.5 (сущности отмечены javax.persistence)

Основные моменты указаний

  • Каждый боб помечен @Repository или @Service должен иметь интерфейс
  • Конструктор DI (когда переконфигурация не требуется)
    • Конструктор имеет по умолчанию видимость (Foo(Bar bar) {...})
  • Поля бина final (когда переконфигурация не требуется)
    • Не приводит к конструктору по умолчанию
  • Реализации по умолчанию видимый с final модификатор (final class Foo)

Проблема

  1. CGLib не может проксировать финальные классы
  2. CGLib требует конструктора по умолчанию (пусто)
  3. Некоторые службы должны быть доступны через JMX
  4. MBean-экспортер не может работать, если не используется прокси-сервер CGLib
  5. К некоторым @Transactional @Service s обращаются через фасадный сервис, который требует более одной службы для включения в транзакцию фасада (например, сервис Observerболее 2 компонентов приложения)
  6. Некоторые интерфейсы имеют несколько реализаций (которые в настоящее время отличаются @Qualifier)
  7. Будущее руководство (или приятно иметь функцию) - каждый модуль приложения будет иметь beanRefContext.xml файл для настройки его внутреннего контекста приложения

Когда я использовал для работы с конфигурацией XML, мне удалось применить все рекомендации, которые я представил выше, но при переходе к аннотациям кажется, что Spring плохо себя ведет.
Разработчики в моей группе предпочитают настройку аннотаций (мне кажется, легче подключать и писать новый код), но я неотразили все виды «хаков», которые они вводят в код, чтобы предотвратить сбои в контексте приложения Spring.

Вопрос (ы)

  1. Есть лилучшие практики, которым я должен следовать при использовании конфигурации аннотаций?
    • При использовании более одной реализации на интерфейс (попытка уменьшить использование @Primary или @Qualifier)
    • При использовании @Transactional
    • При использовании @ManagedResource
    • При использовании комбинации выше
  2. Есть ли способ прекратить работу с CGLib, сохранить конфигурацию аннотаций и все еще иметь возможность экспортировать мои MBeans с аннотациями?
  3. Какова подходящая реализация для соблюдения большинства (желательно всех) моих руководящих принципов?

Ответы [ 2 ]

3 голосов
/ 09 декабря 2010

Я придумал следующее решение (к вопросам № 2 и № 3), чтобы иметь возможность применять мои рекомендации по проектированию и продолжать использовать конфигурацию на основе аннотаций:

  • Каждый зависимый проект (модуль Maven) имеет свой собственный ApplicationContext
  • Каждый зависимый контекст приложения проекта определен в beanRefContext.xml
  • Эти контексты приложения загружаются в иерархии с использованием механизма иерархии контекста Spring.
    • Этот шаг на самом деле не полностью поддерживается Spring и требует дополнительной работы
  • Поскольку мое приложение является многоуровневым, я мог отключить CGLib на всех своих модулях, кроме слоя JMX (я могу жить с ним :-)).

Вышеуказанные шаги также позволили мне сократить время выполнения тестов с поддержкой Spring (каждый модуль загружал только подмножество bean-компонентов).

В качестве практического руководства (для вопроса № 1), если интерфейс имеет более одной реализации, я размещаю @Primary на широко используемых одном и других клиентах, требующих другой реализации, связываем компонент с помощью @Qualifier.

1 голос
/ 30 ноября 2010

Ответ на пункт 2) Вы можете использовать AspectJ вместо CGLib.

...