Ограничение зависимости от весны без потери мощи платформы

Question

Упрощенная архитектура веб-проектов

• WAR

  • внедрение зависимостей пружин (большинство использует XML)

• JAR

  • DAO
  • Домен

Проблема: С пружиной 3 и 2,5+ создание аннотаций Хранилища и сервисы стали намного проще соединять вместе.Тем не менее, потому что часто @Service концептуально принадлежит JAR гораздо больше, чем WAR, и, конечно же, это делают автоматически подключаемые репозитории и транзакционные классы.Как люди работают там, где, как ожидается, не будет «пружинных зависимостей» в реальных классах JAR, что я обнаружил в нескольких компаниях, является целью.

Очевидно, я знаю, что вы не можете удалить ВСЕ пружинные зависимости, если хотитеиспользовать аннотации и транзакции, так как они на самом деле являются весенними классами, но есть ли лучшие практики, которые используют люди, которые ограничивают ответственность, если есть изменения к весне, или есть проекты, которые используют более старые весенние версии в их WAR, чем то, что включено вJAR?

Я предполагаю, что это должно быть распространенной проблемой, но если нет, пожалуйста, спросите, и я уточню

Answer 1

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

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

Обычно я нахожу, что жить с недостатками аннотаций или полностью жить без них (используя Java Config или простой старый XML) являются наиболее приемлемыми вариантами. Пользовательские аннотации являются еще одним бременем обслуживания.

Answer 2

Я уже давно женат на Spring Framework, и мы широко используем его в своей текущей работе. Одним из преимуществ использования Spring является то, что он был спроектирован как можно менее навязчивым, то есть вам редко приходится реализовывать какой-то специфический для Spring интерфейс и т. Д.

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

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