Spring Boot

0

Cześć, może mi ktoś sensownie wytłumaczyć na czym polega Spring Boot razem z jakimiś przykładami w jaki sposób on pomaga w pisaniu webówki w Springu?
To jest tak, że od początku się pisze w spring-boocie?

1

SpringBoot to taki zestaw gotowych konfiguracji Springa do "standardowych zastosowań". Wrzucasz sobie w zależności jakiś spring-boot-starter-parent, robisz maina z @SpringBootApplication i magicznie różne rzeczy zaczynają się dziać same, beany się wykrywają aplikacja startuje servlet, kontrolery się mapują i takie tam. Automatycznie masz w kontekście dostepne różne ciekawe beany jak jakieś metryki na przykład. Dorzucasz spring-boot-starter-jdbc robisz plik properties z informacjami o data source i cyk pojawia sie bean z jdbctemplate skonfigurowanym pod tą bazę... ;]

1

Jak kolega wyżej napisał, Spring Boot autokonfiguruje beany na podstawie tego, co znajdzie na classpathie, w propertiesach itp.

Historycznie chodziło o to, aby w kolejnych projektach nie musieć od nowa konfigurować tych samych rzeczy (jak np. TransactionManager).

ALE każda „magia” ma swoją cenę i ja zawsze polecam nie zaczynać nauki Springa od Spring Boota, ale spróbować samemu skonfigurować taką aplikację od zera. Dlaczego tak? Bo potem pojawiają się pytania na forum pt. „Jakiej adnotacji mam użyć, aby osiągnąć X” :)

0

A będąc już w temacie Springu, w jakiej skali używa się w dzisiejszej produkcji Spring AOP?

2
piotrek2137 napisał(a):

A będąc już w temacie Springu, w jakiej skali używa się w dzisiejszej produkcji Spring AOP?

Oby w żadnej. Najgorsza magia w Springu jest pisana na aspektach

2
piotrek2137 napisał(a):

A będąc już w temacie Springu, w jakiej skali używa się w dzisiejszej produkcji Spring AOP?

J/W
Spring sam w sobie dużo używa AOP (głównie security, transakcje) ale samemu lepiej korzystać albo z technik OOP (kompozycja, proxy/dekorator) albo z FP (higher order function)
Zamiast używac np. AOPa do cachowania lepiej stworzyć rzeczywista klase (nie mam na mysli dynamic proxy) która będzie przechwytywac wywowłanie metod z klasy której wyniki cachujemy zamiast polegac na cudach AOPa

1

Akurat z obecnością AOP w projektach komercyjnych parę razy się spotkałem. Głównie do logów audytowych i performance'owych, czasem do cache'owania. Moim zdaniem warto wiedzieć z czym się to je, aby znać wady i zalety tego podejścia.
Polecam też przesłuchać ( tutaj akurat raczej o wadach AOP na przykładzie adnotacji @Transactional, która z wykorzystaniem tegoż AOP działa):

0

Wbiję kij w mrowisko, ale pytanie było czy się używa i odpowiedz brzmi: tak. Jest to mechanizm służący do ogrywania tzw. cross-cutting concerns.

Użycie @Transactional, @PreAuthorize czy @HystrixCommand jest na porządku dziennym. Wszelkie odstępstwa to albo brak wsparcia biblioteki (np. Resilience4j, ale pewnie do czasu), albo próba ograniczenia magii (np. stosując prog. funkcyjne) - słuszne, ale nie jest to podejście powszechne IMHO.

1

@Charles_Ray: "jedzmy g**no miliony much nie moga się mylić"
Akurat transactional łatwo opędzlować TransactionTemplate
poza tym jeśli będziemy zgadzać się na syf w kodzie to syf zostanie, a mimo wszystko pewne idee coraz bardziej przebijają się do mainstreamu (np. o mockosturbacji)

0
  1. Nie słyszałem określenia "mockosturbacja", raczej "overmocking". Rozumiem, że wzorujesz się na @jarekr000000, który chyba jest autorem tego określenia.
  2. Overmocking to w większości przypadków (oczywisty) błąd, natomiast nie nazwałbym użycia annotacji błędem. To kwestia wyboru rozwiązania, które opiera się na różnych driverach. Świat nie jest czarno-biały.
  3. Mówiłem, że wbiję kij w mrowisko :)
1

@Charles_Ray:
co jeśli na metodzie masz @cacheable i @transactional?
Będzie cachować a później robić transakcje czy najpierw robić transakcje i cachować?
A może będzie cachować i robić transakcje później?
A jesli masz 3 adnotacje, to która się wykona po której?

0

To jest bardzo proste.

  1. Nie rób tego na jednym komponencie jeśli nie musisz (kwestia architektury aplikacji, zwykle da się tego uniknąć)
  2. Napisz test integracyjny, który udokumentuje zachowanie
  3. Mocno trywializujesz problem. Zdaję sobie sprawę z problematycznych case'ów przy użyciu AOP. Pominąłeś jednak cały kontekst wyboru takiego, a nie innego rozwiązania. To tak jakbyś mnie zapytał dlaczego programista zrobił X, a powinien Y. Nie wiem dlaczego podjął taką decyzję, może miał dobre powody :)
1

1.Czyli możesz użyć kompozycji, np. wzorca dekorator. Normalna technika z OOP. Po co korzystac z magii jak możesz np. wywołac sobie normalnie hazelcasta i móc to zdebugować?
2.No chyba że zaciągnie innego magicznego jara, albo zapomnisz włączyć super magicznej adnotacji ze Spring Boota.
A tak w ogóle widzisz że transactional nie działa, co robisz? Jak to zdebugujesz?

0

Można pisać własne dekoratory i to jest bardzo OK, a można skorzystać z gotowych aspektów z całym inwentarzem. Ja nie twierdzę, że jest to technologia doskonała, natomiast mam alergię na „twarde opinie” :) ja używam i nie mam z tym żadnego problemu

1

Czyli jak powiem że powinno sie testowac kod to tez wzbudzi Twój przeciw bo to "twarda opinia"
A jak napisze że tworzenie klas na 5000 lini kodu też, bo to "twawda opinia"?

0

A jak powiesz, że trzeba oddychać albo nie wolno skakać z 10 piętra? Spierajmy się proszę na poziomie.

1 użytkowników online, w tym zalogowanych: 0, gości: 1