Przez długi czas wierzyłem, że warto mieć „scentralizowaną, deklaratywną konfigurację”, taką jak pliki xml, których wszyscy używaliśmy. Potem zdałem sobie sprawę, że większość rzeczy w plikach nie była konfiguracją - nigdy nie została zmieniona po opracowaniu, nigdy. Potem zdałem sobie sprawę, że „scentralizowany” ma wartość tylko w dość małych systemach - tylko w małych systemach będziesz w stanie uruchomić plik konfiguracyjny jako całość . Jaka jest naprawdę wartość zrozumienia okablowania jako całości, kiedy te same „okablowanie” są w większości powielane przez zależności w kodzie? Więc jedyne, co zachowałem, to metadane (adnotacje), które wciąż są w pewnym sensie deklaratywne. Te nigdy się nie zmieniają w czasie wykonywania i nigdy nie są dane „konfiguracyjne”, które ktoś zmieni w locie - więc myślę, że trzymanie ich w kodzie jest fajne.
Korzystam z pełnego automatycznego okablowania w miarę możliwości. Kocham to. Nie wrócę do wiosny w starym stylu, chyba że zostanie mi to zagrożone. Moje powody, dla których w pełni preferowałem @Autowired, zmieniły się z czasem.
W tej chwili uważam, że najważniejszym powodem korzystania z automatycznego okablowania jest to, że w twoim systemie jest o jedną abstrakcję mniej do śledzenia. „Nazwa fasoli” zniknęła. Okazuje się, że nazwa fasoli istnieje tylko z powodu xml. Tak więc nie ma pełnej warstwy abstrakcyjnych pośrednich (gdzie można połączyć nazwę fasoli „foo” w „pasku” fasoli). Teraz podłączam interfejs „Foo” bezpośrednio do mojej fasoli, a implementacja jest wybierana na podstawie profilu działania. To pozwala mi pracować z kodem podczas śledzenia zależności i implementacji. Kiedy w kodzie widzę zależną od siebie zależność, mogę po prostu nacisnąć klawisz „przejdź do implementacji” w moim IDE i pojawia się lista znanych implementacji. W większości przypadków jest tylko jedna implementacja i jestem bezpośrednio w klasie. Mogą' jaka implementacja jest używana (twierdzę, że odwrotność jest bliższa prawdy z okablowaniem xml - zabawne, jak zmienia się twoja perspektywa!)
Teraz możesz powiedzieć, że to tylko bardzo prosta warstwa, ale każda warstwa abstrakcji, którą dodajemy do naszych systemów, zwiększa złożoność. Naprawdę nie sądzę, że xml kiedykolwiek dodał jakąkolwiek prawdziwą wartość do jakiegokolwiek systemu, z którym pracowałem.
Większość systemów, z którymi kiedykolwiek pracowałem, ma tylko jedną konfigurację środowiska wykonawczego produkcji. Mogą istnieć inne konfiguracje do testowania i tak dalej.
Powiedziałbym, że pełne automatyczne okablowanie to rubinowa szyna wiosny: obejmuje ona pogląd, że istnieje normalny i powszechny wzorzec użytkowania, który stosuje większość przypadków użycia. W konfiguracji XML zezwalasz na wiele spójnych / niespójnych zastosowań konfiguracji, które mogą / nie mogą być zamierzone. Widziałem, jak wiele konfiguracji xml przesadza z niespójnościami - czy jest refaktoryzowana wraz z kodem? Nie myślałem Czy te odmiany istnieją z jakiegoś powodu? Zwykle nie.
W naszej konfiguracji prawie nie używamy kwalifikatorów i znaleźliśmy inne sposoby rozwiązania tych sytuacji. Jest to wyraźna „wada”, z którą się spotykamy: nieznacznie zmieniliśmy sposób, w jaki kodujemy, aby działała płynniej dzięki automatycznemu okablowaniu: repozytorium klientów nie implementuje już ogólnego Repository<Customer>interfejsu, ale tworzymy interfejs, CustomerRepositoryktóry się rozszerza Repository<Customer>. Czasami istnieje również sztuczka, jeśli chodzi o podklasę. Ale zwykle po prostu wskazuje nam kierunek silniejszego pisania, co moim zdaniem jest prawie zawsze lepszym rozwiązaniem.
Ale tak, przywiązujesz się do określonego stylu DI, który robi głównie wiosna. Nie tworzymy już publicznych ustawień zależności (więc możesz argumentować, że mamy +1 w dziale enkapsulacji / ukrywania informacji) Wciąż mamy trochę xml w naszym systemie, ale xml zasadniczo zawiera tylko anomalie. Pełna automatyczna integracja ładnie integruje się z xml.
Jedyne, czego teraz potrzebujemy, to @Component, @Autowiredaby reszta została włączona do JSR (jak JSR-250 ), więc nie musimy wiązać się ze wiosną. Tak było w przeszłości ( java.util.concurrentrzeczy przychodzą mi do głowy), więc nie byłbym całkowicie zaskoczony, gdyby to się powtórzyło.