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.