Rest a relacje między encjami

2015-02-05 11:12
Wielki Pomidor
0

Cześć

Mamy jakąś aplikację, która wystawia RESTa. W modelu mamy dajmy na to kategorie i podkategorie.
I teraz czy jest jakiś sens w implementowaniu relacji pomiędzy tymi dwoma encjami. Chodzi mi o to że jak ktoś zrobi GETa o kategorie to po co pchać w odpowiedzi
i podkategorie dla każdej kategorii. Nie lepiej jest zapytać najpierw o listę kategorii, a potem na podstawie id kategorii pobrać podkategorię. Mamy więcej zapytań, ale czy nie będzie to lżejsze? Jeśli jest związany jakiś termin z tym zagadnieniem to napiszcie. Z chęcią sobie więcej o tym poczytam.
Z góry dzięki.

Pozostało 580 znaków

2015-02-05 11:34
0

Jeżeli używasz orm, to najprawdopodbniej możesz robich fetcha i wybrać czy w zapytaniu chcesz pobrać tylko kategorie, czy kategorie i podkategorie. Zatem implementacyjnie robisz relację, ale to czy jej użyjesz to już zależy od Ciebie.

Natomiast jeżeli chodzi o samo użycie to musisz sam zdecydować jak będzie szybciej. Jeżeli jesteś pewny że ktoś na bank przejrzy wszystkie kategorie, albo nawet 2 czy 3 to lepiej zrobić fetcha. Jeżeli kategorii jest np. 10 czy 20 to szybciej jest pobrać wszystkie razem niż zrobić 2 zapytania o kategorię i podkategorię. No chyba że przewidujesz że ktoś wcale nie musi być zainteresowany rozwijaniem kategorii bo robisz stronkę SPA i dociągasz bo ma się wyświetlić na ekranie.

Pozostało 580 znaków

2015-02-05 13:09
Wielki Pomidor
0

Właśnie, jak chcę zrobić SPA angularem to najlepiej ładować oddzielnie i w modelu bez relacji?
Np. oddzielny controller dla kategorii i oddzielny do podkategorii.
A orm będzie używany, a kategorie to jest przykład, bo chcę zrobić coś jak trello w celach edukacyjnych i jak patrzyłem na ich odpowiedzi to w json zwracają board, a dopiero potem dociągają notatki.

Pozostało 580 znaków

2015-02-05 14:19
0

To zależy co chcesz uzyskać w kliencie.

1. Chcesz mieć szybki dostęp do kategorii, a dodatkowe żądanie o podkategorie nie zaboli

Wysyłasz tylko listę kategorii. Po stronie GUI kliknięcie w kategorię wysyła kolejne żądanie o podkategorie.

zalety

  • proste
  • łatwe
  • przyjemne
    Wady
  • duży narzut na ruchu sieciowym ponieważ do danych z podkategorii dorzucasz "requestującą" część żądania.

2. Chcesz ograniczyć ilość żądań, ale akceptujesz dłuższy czas odpowiedzi

Wysyłasz wszystko jak leci. Angular zbuduje z tego drzewo w oparciu o ul, li itp.

zalety

  • prostsze po stronie serwera
  • lepiej opisuje się za pomocą porównań do ORM (encja, relacja jeden to wielu, kolekcja itp.)
  • jedno żądanie

wady

  • odpowiedź będzie zachłanna. Przy bardzo rozbudowanym drzewie GUI zwolni.
  • trzeba umieć obsłużyć zmiany w kategoriach w czasie (żądanie sprawdzające zmianę!)

Pozostało 580 znaków

2015-02-05 14:25
Wielki Pomidor
0

@Koziołek miałem nadzieję, że Ty albo ktoś inny na to zerknie :P dzięki

mógłbyś dokładniej wyjaśnić ten podpunkt o zmianie w kategorii i sprawdzaniu, jakiś przykład?

Z góry dzięki!

Pozostało 580 znaków

2015-02-05 15:30
0
  • A otwiera aplikację
  • A otrzymuje cały model kategorii
  • B otwiera aplikację
  • B otrzymuje cały model kategorii
  • B zmienia coś w kategoriach
  • A nie widzi zmian.

Musisz w jakiś sposób śledzić zaistnienie zmiany. IMO, najszybciej idzie wraz z modelem wysyłać jego wersję. W momencie zmiany w modelu zmienia się wersja. A wysyała co pewien czas lekki request do serwera o to czy zmiana istnieje. Jeżeli tak to pobiera nowe drzewo.

Pozostało 580 znaków

2015-02-05 15:36
Wielki Pomidor
0

Super, dzięki za wszystkie odpowiedzi.
A jak sprawa wygląda w praktyce, któreś rozwiązanie jest preferowane (best practice)?

Dzięki.

Pozostało 580 znaków

Liczba odpowiedzi na stronę

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