foobarek
foobarek
  • 0
W ramach nauki dłubie sobie prosty projekt w Spring Boocie i dostałem zaćmienia już w fazie projektowania... Może ktoś dobroduszny pomoże?

W uproszczeniu, mam klasy:
Pracownik (id, imię, login, haslo)
Szkolenie (id, nazwa, listaObecnosci)

Chodzi ogólnie o to, żeby pracownik, który był na jakimś konkretnym szkoleniu, zaznaczył na nim swoją obecność (czyli w sumie chodzi o taką jakby listę obecności).

Póki co wymyśliłem, że dodam nową klasę Obecność, która będzie w relacji
moriturius
moriturius
  • 0
@Emil1803: Spoko main bus, tylko musisz zostawiać o wiele więcej miejsca na produkcję stuffu. Main bus ma tę wadę, że podstawowych materiałów schodzą tony więc musisz dbać o dobre zasilanie płytkami i zielonymi circuitami.
Dodatkowo - rzeczy takie jak koła zębate i drut miedziany lepiej wytwarzać bezpośrednio w miejscu gdzie ich potrzebujesz, niż ciągnąć po main busie.

BTW: ja jestem wielkim fanem fabryk spaghetti. Nie lubie main busów :<
moriturius
moriturius
  • 0
@Emil1803: Jak zastanawiam się czy coś powinno iść na main bus to biorę pod uwagę dwa czynniki:
1) czy można to szybko wyprodukować na miejscu (np. miedziane druty, koła zębate)
2) czy to jest coś z czego korzysta wiele innych przepisów (green circuit, red circuit)

Bo np. nie ma dużej potrzeby robienia 12 pasów z kołami zębatymi jak wystarczą często 1 - 2 fabryki na miejscu . Tak samo nie ma
moriturius
moriturius
  • 1
@noarch: W takim razie sprawa jest dość prosta. W każdym z serwisów powinieneś oddzielić model domenowy danego serwisu od modelu komunikacyjnego (np. danych zwracanych na endpointach, lub w klientach do innych usług). Potem trzeba tylko napisać kawałek kodu do konwertowania jednego modelu na drugi.

Niestety jest to sporo pisania ale daje Ci dużą swobodę w modyfikacji każdego modelu osobno bo konwerter zawera informację co tłumaczysz na co i jest jedynym punktem,
moriturius
moriturius
  • 1
@noarch: Jeśli jeden pakiet potrzebuje danych prywatnych drugiego pakietu to może być to jedna z takich sytuacji:
1) Prywatne dane drugiego pakietu nie są tak na prawdę prywatne i trzeba je wstawić na jakimś interfejsie komunikacyjnym
2) Coś jest nie tak z odpowiedzialnościami i/lub rzeczy są zbyt mocno podzielone. Wtedy trzeba się dobrze zastanowić nad tym co się tak na prawdę dzieje.

Dodam tylko, że ogólnie te wszystkie zasady odnośnie układania
moriturius
moriturius
  • 0
@noarch: Mam wrażenie, że to o czym piszesz w pkt. 2 to jest dokładnie to co opisałem. Trudno mi tak na prawdę doradzić coś sensownego, bo widzę, że masz jakiś konkretny problem w konkretnym projekcie i bez zobaczenia jak to jest i co właściwie stanowi problem chyba nie pomogę bardziej.
C.....J
C.....J
  • 4
"Generic wildcard types should not be used in return parameters"
Czy w kontrolerach restowych złym nawykiem jest zwracanie obiektu typu wildcard? Bo generalnie jest to słaba praktyka? Pytanie jak w przypadku kontrolerów, dla przykładu mam Restowe API i wciągamy dane i zwracamy je w odpowiedzi http z jsonem. Metody z kontrolerów zwracają ResponseEntity . Pytanie czy nie lepiej od warstwy serwisowej wiedzieć co zwracamy i taki typ przyjąć w obiekcie ResponseEntity w
moriturius
moriturius
  • 0
Mamy sytuację, że wywołanie danego endpointu powinno zakończyć się Http 200, ale dany request może zajmować różny czas i dla dłuższego przetwarzania requestów chcielibyśmy zwrócić klientowi Http 202, w metodzie z adnotacją @ResponseStatus byłoby to niemożliwe


W moim rozumowaniu to właśnie @ResponseStatus uratuje Twoje API przed pochopnymi decyzjami ;)

Dany endpoint powinien działać w jeden konkretny sposób. Klient musi wiedzieć czy dostanie odpowiedź, czy musi później o zapytać o status żądania. Taki

Osiągnięcia