Mam aplikacje w #java #spring (backend) z JS SPA na froncie. Mam elementy ktore uzytkownik moze sortowac przeciagajac elementy. Ja musze zas zapisac ta kolejnosc do DB. Przesuniecie elementu powoduje przesuniecie go w tablicy elementow wiec widoczna,zmodyfikowana kolejnosc jest odzwierciedlona w kolejnosci w tablicy.
Najprosciej, bez zbednego przetwarzania na froncie, moge wyslac cala tablice elementow, zmapowac ja do List i iterujac for'em wrzucic .setSequence(i) i zapisac.
Niemniej zastanawiam sie czy to rzeczywiscie najlepsze rozwiazanie.
Jakies sugestie?
Zastanawialem sie czy w backendzie nie wymagac DTO z id elementu i sequence number tylko, ale wtedy na kazdy update dochodzi mi select bo musze pobrac najpierw findById i dopiero wtedy ustawic sequence.
Złym nawykiem jest próba mikrooptymalizacji na etapie implementacji. Każde z zaproponowanych przez Ciebie rozwiązań jest dobre, każde z nich działa, i każde jest lepsze lub/i gorsze od innych pod pewnymi względami.
Jeden rabin powie, że lepiej mieć więcej kodu, ale mniej selectów, inny, że więcej selectów, ale mniej kodu. Itp., itd.
@trustME: czego uzywasz po stronie frontu do realizacji tego zadania? Robilem podejscie do draguli (a konkretnie jej wrappera na vue.js) ale nie bylem zadowolony z wynikow.
Mam elementy ktore uzytkownik moze sortowac przeciagajac elementy. Ja musze zas zapisac ta kolejnosc do DB.
Przesuniecie elementu powoduje przesuniecie go w tablicy elementow wiec widoczna,zmodyfikowana kolejnosc jest odzwierciedlona w kolejnosci w tablicy.
Najprosciej, bez zbednego przetwarzania na froncie, moge wyslac cala tablice elementow, zmapowac ja do List i iterujac for'em wrzucic .setSequence(i) i zapisac.
Niemniej zastanawiam sie czy to rzeczywiscie najlepsze rozwiazanie.
Jakies sugestie?
Zastanawialem sie czy w backendzie nie wymagac DTO z id elementu i sequence number tylko,
ale wtedy na kazdy update dochodzi mi select bo musze pobrac najpierw findById i dopiero wtedy ustawic sequence.
Sorry jak chaotycznie.
#programowanie
@trustME: Najlepsze to takie, które działa.
@trustME: a czy to powoduje jakieś problemy wydajnościowe?
Złym nawykiem jest próba mikrooptymalizacji na etapie implementacji. Każde z zaproponowanych przez Ciebie rozwiązań jest dobre, każde z nich działa, i każde jest lepsze lub/i gorsze od innych pod pewnymi względami.
Jeden rabin powie, że lepiej mieć więcej kodu, ale mniej selectów, inny, że więcej selectów, ale mniej kodu. Itp., itd.