[r.....s]

#programowanie #dotnet #orm #entityframework
Mireczki mam taką sytuację, że posiadam użytkownika który posiada własne zamówienia (relacja nr.1) i może oglądać zamówienia swoich podopiecznych (relacja 2). Teraz chciałbym użytkownikowi wyświetlić dane z obu relacji w jednym widoku. Teraz jak do tego podejść. Pobrać z bazy danych obiekt użytkownika z dołączonymi obiema listami. (mam na myśli Include z ef, albo fetch z hibernate) i potem przemapować na jakiś view model czy może napisać jakieś query które ogarnie mi to po stronie serwera? Pierwsze podejście ma taki plus, że gdziekolwiek będę pobierał dane związane z użytkownikiem będę robił to używając jednego obiektu. Łatwo będzie to utrzymywać. Z drugiej strony jest mocny overhead jeżeli chodzi o pobierane dane i performance. Idea numer jeden wydaje mi się bardziej spójna z DDD bo mamy ten obiekt użytkownika który agreguje sobie jakieś zamówienia etc. Jest jeszcze problem z inicjalizacją obiektu użytkownika. Załóżmy, że chcielibyśmy wyciągnąć wszystkie zamówione rzeczy z wszystkich zamówień użytkownika i zsumować ilości poszczególnych przedmiotów. Po pierwsze musimy przy tworzeniu obiektu użytkownika musimy pamiętać żeby dołączyć całe drzewko encji po drugie wyciąganie tego wszystkiego i potem grupowanie po stronie servera trwałoby wieki.
Moje pytania do was:
1. Tworzycie osobne zapytania do poszczególnych widoków w aplikacjach? Jak nazywacie te obiekty które zwracają wam coś takie hmm można powiedzieć agregaty?

2. Co z logiką która występuje w zapytaniach. Tzn oprócz wyciągnięcia jakichś danych musicie dodatkowo coś wyliczyć. Trzymając się zamówień może to być np prawo do modyfikacji zamówienia w oparciu o jakieś zasady. Nie trzymamy tego w bazie danych i może się to przewijać przy wielu widokach. Przy wyborze opcji każdy widok ma swoje query będzie redundancja kodu.

Pozdrawiam tych co kucują w sobote wieczorem : )

[zackson]

@rydes: piatek dzisiaj

[MacDada]

@rydes: Naucz się pisać z akapitami, bo ściana tekstu.