Nasza strona używa cookies. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Poznaj 6 złych praktyk w Springu

Ali Zeynalli Senior Software Engineer
Sprawdź, jak możesz ułatwić sobie pracę w Springu, unikając 6 częstych błędów.
Poznaj 6 złych praktyk w Springu

Framework Spring wraz ze Spring Boot i Spring MVC są najbardziej popularnymi frameworkami używanymi w świecie Javy. Im więcej się z niego korzysta, tym więcej nieuchronnie pojawia się złych i dobrych praktyk. Z drugiej jednak strony, Spring Boot ma sporo konwencji i wytycznych. A więc bez zbędnego gadania, w tym artykule postaram się pokazać kilka antywzorców, których stosować nie powinieneś.


Spring DI

Wybieraj wstrzykiwanie przez konstruktor zamiast wstrzykiwanie przez pola i settery. Beany wstrzykiwane przez pola są trudne do przetestowania, podatne na zależności cykliczne oraz są bardzo podatne na problemy wynikają z mutowalności. Aby zależność stała się final, zmienna @Autowired wymaga dodatkowych adnotacji (@Autowired(required = false) lub @Lazy). Podobny mankament widoczny jest przy wstrzykiwaniu przez settery. Dodatkowo wstrzykiwanie przez settery powoduje powstawanie powtarzalnego kodu. Najlepszym więc rozwiązaniem jest wstrzykiwanie przez konstruktor, i to rozwiązanie jest także oficjalnie zalecane w Springu. Dzięki tej metodzie łatwo jest uczynić zmienne niemutowalnymi. Łatwo wykryć rozszerzenie zależności, ponieważ konstruktor rozszerza się razem z nimi.

// Field Injection => not recommended
import org.springframework.beans.factory.annotation.Autowired;

public class ExampleBean {
   @Autowired
   private SomeBean someBean;

   //some business code here...
}

// Setter injection => not recommended
import org.springframework.beans.factory.annotation.Autowired;

public class ExampleBean {
   private SomeBean someBean;

   @Autowired
   public void setSomeBean(final SomeBean someBean) {
       this.someBean = someBean;
   }

   //some business code here...
}
// Constructor injection => recommended

public class ExampleBean {
   private final SomeBean someBean;

   public SomeBean(final SomeBean) {
       this.someBean = someBean;
   }

   //some business code here...
}


Zapomnij o konfiguracji opartej na XML


Konfiguracja aplikacji w Spring za pomocą XML jest obecnie mocno odradzana. Konfiguracja taka powoduje powstawanie powtarzalnego kodu, i jest tak obszerna, że niezwykle trudno ją odczytać i przeszukiwać w IDE. Najlepszym sposobem jest użycie konfiguracji opartej na adnotacjach w kodzie. Łatwo to opanować i jest to bardziej czytelne podejście dla programistów.


Niewłaściwe testowanie

Testowanie aplikacji webowych w Spring jest często lekceważone. Bardzo niewiele zespołów posiada szczegółowe pokrycie testowe aplikacji Spring Boot z dobrze przygotowanymi testami integracyjnymi. Upewnij się, że zespół programistów jest świadomy tego jak ważne jest testowanie funkcji. Takie rozwiązanie oferuje framework testowy w Springu.


Nie buduj nowej aplikacji ręcznie od podstaw

Wielu programistów tradycjonalistów uwielbia, kiedy mają pełną kontrolę nad aplikacją. Próbują więc ręcznie utworzyć plik pom i skonstruować aplikację od podstaw. Spring posiada łatwe w użyciu i poręczne narzędzie o nazwie Spring Initializr, które tworzy aplikację Spring Boot z poprawnie dobranymi zależnościami i właściwą strukturą. Jest to zalecany sposób na oficjalne generowanie nowych aplikacji Springa, a obecne IDE, takie jak Eclipse Intellij, posiadają wtyczki zewnętrzne dla Spring Initializr.


Niedostateczne logowanie

Niedostateczne logowanie to utrapienie dla każdego produktu. Szczególnie gdy pojawiają się błędy w środowisku produkcyjnym. Problemy z logowaniem utrudniają pracę każdemu programiście, ponieważ szuka on przyczyny na ślepo. LogBack jest potężnym frameworkiem, dlatego upewnij się, że używasz go poprawnie.


Nie integruj Springa z podstawową logiką biznesową

Znana książka „Czysta architektura” R. C. Martina utrzymuje, że kod logiki biznesowej powinien być wolny od jakichkolwiek zewnętrznych frameworków, baz danych, UI. Jeśli domena jest wolna od frameworka, to jutro, gdy framework zniknie, kod biznesowy nie stanie się długiem technologicznym. Tak więc klasy domenowe nie powinny mieć żadnych adnotacji Springa jak @Component, @Autowired, @Service, ale zamiast tego powinny być prostymi klasami Javy, które są tworzone w tradycyjny sposób.

// Bad Practice
@Component
public class ExampleClass {
    @Autowired
    private SomeClass someClass;

    // some business code here
}
//Good Practice
public class ExampleClass {
    private final SomeClass someClass;

    public ExampleClass(SomeClass someClass) {
        this.someClass = someClass;
    }

    // some business code here
}


Oryginał tekstu w języku angielskim przeczytasz tutaj.

Rozpocznij dyskusję

Lubisz dzielić się wiedzą i chcesz zostać autorem?

Podziel się wiedzą z 160 tysiącami naszych czytelników

Dowiedz się więcej