Тривалий час я вважав, що є значення в наявності "централізованої, декларативної, конфігурації", як файли xml, які ми всі використовували. Тоді я зрозумів, що більшість речей у файлах не має конфігурації - вона ніколи не змінювалася ніде після розробки, ніколи. Тоді я зрозумів, що "централізоване" має значення лише в досить малих системах - лише в невеликих системах ви зможете виправити файл конфігурації в цілому . І яка насправді цінність розуміння проводки в цілому, коли ті самі «проводки» здебільшого дублюються залежностями в коді? Тож єдине, що я зберігав - це метадані (анотації), які все ще є декларативними. Вони ніколи не змінюються під час виконання, і вони ніколи "конфігураційні" дані, які хтось змінить на ходу - тому я думаю, що зберігати їх у коді приємно.
Я використовую повну автоматичну проводку стільки, скільки можу. Я це люблю. Я не повернусь до весни старого стилю, якщо не погрожуватиму на пушці. Мої причини віддати перевагу повністю з @Autowiredчасом змінилися.
Зараз я думаю, що найважливішою причиною використання автоматичної проводки є те, що у вашій системі є одна менша абстракція, яку слід відстежувати. "Ім'я квасолі" фактично не зникло. Виявляється, назва квасолі існує лише через xml. Таким чином, повний шар абстрактних непрямих (де ви переведете назву квасолі "foo" в бобову "бар") немає. Тепер я з'єдную інтерфейс "Foo" безпосередньо в моєму квасолі, і реалізація вибирається профілем часу виконання. Це дозволяє мені працювати з кодом при відстеженні залежностей та реалізації. Коли я бачу в моєму коді автоматичну провідну залежність, я можу просто натиснути клавішу "перейти до реалізації" в моєму IDE і з'являється список відомих реалізацій. У більшості випадків є лише одна реалізація, і я прямо в клас. Можна " яка реалізація використовується (я стверджую, що навпаки ближче до істини за допомогою xml-проводки - смішно, як змінюється ваша перспектива!)
Тепер ви можете сказати, що це просто дуже простий шар, але кожен шар абстракції, який ми додаємо до наших систем, збільшує складність. Я дійсно не думаю, що xml ніколи не додавав реальної цінності будь-якій системі, з якою я працював.
Більшість систем, з якими я коли-небудь працював, мають одну конфігурацію виробничого середовища. Можуть бути й інші конфігурації для тестування тощо.
Я б сказав, що повна автоматична проводка - це рубін рейки весни: вона охоплює уявлення про те, що існує нормальна і загальна схема використання, за якою слідує більшість випадків використання. З конфігурацією XML ви дозволяєте безліч послідовних / непослідовних використання конфігурації, які можуть / не можуть бути призначені. Я бачив, що стільки конфігурацій XML переповнюють непослідовність - чи вона переробляється разом з кодом? Не думав. Чи є ці варіанти з причини? Зазвичай ні.
Ми майже не використовуємо класифікаторів у нашій конфігурації та знаходили інші способи вирішення цих ситуацій. Це очевидний "недолік", з яким ми стикаємося: ми дещо змінили спосіб кодування, щоб зробити його більш взаємодіючим з автоматичним підключенням: репозиторій клієнтів більше не реалізує загальний Repository<Customer>інтерфейс, але ми робимо інтерфейс, CustomerRepositoryякий розширюється Repository<Customer>. Іноді також є хитрість чи два, коли мова йде про підкласи. Але зазвичай це просто спрямовує нас у напрямку сильнішого набору тексту, що, як я вважаю, майже завжди є кращим рішенням.
Але так, ви прив’язуєтесь до певного стилю DI, який переважно весна. Ми навіть не робити публічні сеттери залежностей більше (Таким чином , можна стверджувати , що ми +1 в відділі інкапсуляція / приховування інформації) У нас ще є деякі XML в нашій системі, але XML у основному тільки містить аномалії. Повна автопроводка чудово інтегрується з xml.
Єдине, що нам зараз потрібно - це включити решту @Component, @Autowiredа решту включити до JSR (як, наприклад, JSR-250 ), тому нам не доведеться пов'язувати весну. Це те, що відбувалося в минулому ( java.util.concurrentречі припадають на розум), тому я не був би зовсім здивований, якби це повторилося.