Czy Spring jest na pewno taki zły?

Cześć,

Pewnego dnia, gadałem z kolegą (2-letnim midem), ogólnie o Springu, i powiedział taką rzecz:

jeżeli klasy są bezstanowe, to lepiej żeby nimi zarządzał Spring, bo inaczej niepotrzebnie zapychasz sobie pamięć.

I teraz mam mindf**k, bo na różnych prezentacjach i konferencjach, ludzie mówią o tym, żeby było jak najmniej klas zarządzanych przez Springa, czyli np. tylko Fasada, jako wejście do konkretnego punktu domeny, Kontroler i ew. repozytorium Spring Data. I moje pytanie jest takie, co jest przewagą takiego podejścia (czyli tworzenia zależności w klasach konfiguracyjnych, lub ręcznie, przez new), nad podejściem, gdzie wszystkie serwisy, walidatory itp. są zarządzane przez Springa? Czy nie zaśmiecamy sobie niepotrzebnie pamięci poprzez tworzenie wszystkich zależności przez new?

Czy nie zaśmiecamy sobie niepotrzebnie pamięci poprzez tworzenie wszystkich zależności przez new?

A to Spring tworzy zależności przez delete czy stosuje jeszcze jakąś inną magię?

2-letnim midem

xD

Anyway gada bzdury. Pamięci zużywasz tyle samo, a pewnie nawet i więcej, bo spring ma jakiśtam overhead. Jednocześnie myśle że istotna jest spójność w projekcie. Jeśli masz część takich obiektów zarządzanych przez springa, a inne nie, to może być ciężko się w tym połapać, z punktu widzenia programisty, co może prowadzić do błędów. Programowanie to praca zespołowa i kluczowe jest, żebyś czytając kod, rozumiał co się dzieje i skąd sie bierze.

Shalom napisał(a):

Jednocześnie myśle że istotna jest spójność w projekcie. Jeśli masz część takich obiektów zarządzanych przez springa, a inne nie, to może być ciężko się w tym połapać, z punktu widzenia programisty, co może prowadzić do błędów

Ciekawe jak programiści springamiści radzą sobie z Integerami, Stringami i ArrayListami? Nie żebym nie widział prób zrobienia tego springiem...
Nigdzie nie widziałem takiego gubienia się w kodzie jak w projekcie, gdzie ten spring był doprowadzony konsekwentnie do końca i mało który objekt nie był spring beanem (oj to był rak nad raczyska).

chivy napisał(a):

czyli tworzenia zależności w klasach konfiguracyjnych, lub ręcznie, przez new
(...)
Czy nie zaśmiecamy sobie niepotrzebnie pamięci poprzez tworzenie wszystkich zależności przez new?

Zwróciło mi się uwagę na te zdanie. Przede wszystkim zdaj sobie sprawę, że nie tworzysz zależności ręcznie przez new w środku klas - tym sposobem nie będziesz mógł ich łatwo testować - ale testowanie ich też bym Ci odradzała. Cały ten moduł piszesz tak jak w springu - jeżeli tworzysz moduł "communicator" i klasa Communicator potrzebuje jeszcze logiki od klasy Speaker to po prostu zrób sobie klasę CommunicatorFactory, która będzie mieć w środku metodę create i dopiero ta metoda w tej fabryce przez new wstrzyknie do klasy Communicator instancję Speakera. A gdyby klasa Communicator potrzebowała jeszcze zależności do jakiegoś repo IO albo innego zewnętrznego klocka fasady spoza modułu to zrób sobie metodę create w CommunicatorFactory, która przyjmie te rzeczy w parametrach i wstrzyknie do Communicator. Tym sposobem jeżeli dla tych fasad stosujesz interfejsy to możesz łatwo te klocki se mockować i testować całe klocki mokując np. API zewnętrznego systemu czy warstwę IO i przekazując mocki do fabryki. Fajnie wgle, że całe te testy można pisać bez stawiania springa, praktycznie czysto funkcyjnie w czystym spocku. Na pierwszy rzut oka trudno jest tak pisać moduły bez użycia springa, ale to da się zrobić i dzięki temu takie podejście wymusza Ci to, że te moduły mają być małe i nie przekombinowane. Mając trochę takich klocków potem możesz je łatwo testować i stosując te klocki poskładać sobie system do kupy a każdy klocek wydzielić nawet jako osobny projekt/bibliotekę. Te klocki jedynie rejestrujesz w kontenerze springa i tyle.