domain model - czy zawsze budować cały

Zastanawia mnie pewna kwestia odnośnie budowania obiektu modelu domenowego w webaplikacjach. Mój problem przedstawię na konkretnym przykładzie:

Dla uproszczenia załóżmy że mamy klasę BankAccount posiada ona właściwości: numer konta, data otworzenia, listę transakcji oraz metodę zwracającą aktualne saldo.
Teraz chcemy na pewnej podstronie wyświetlić numer konta oraz saldo dla pewnego obiektu BankAccount, czy w takiej sytuacji należy pobrać z bazy wszystkie dane powiązane z tym kontem czy tylko to co jest na potrzebne do wyświetlenia danych.

Oczywiście w tej sytuacji odczytanie z bazy jednego pola więcej nie jest problemem, ale w prawdziwych zastosowaniach tych zbędnych danych bywa dużo więcej.

Pobierając tylko to co potrzeba zyskujemy na szybkości wykonania, ale z drugiej strony zbudowany przez nas model nie jest zgodny w 100% ze stanem faktycznym. Co jest w takiej sytuacji dobrą praktyką ?

Czemu niby model będący projekcją faktycznych danych, miałby nie być zgodny ze stanem faktycznym?

Dobrą praktyką, jest nie wymyślać problemów, zanim nie nastąpią. Masz jakiś konkretny problem wydajnościowy w istniejącej aplikacji?

Czytałem w książce a i nawet nam prowadzący o tym mówił żeby do widoków przekazywać tylko tyle danych ile jest potrzebnych. Na przykład nie przekazywać numeru konta bankowego skoro nam do niczego nie będzie potrzebny. Dodatkowo w ASP.NET MVC w tym celu tworzy się ViewModel który zawiera adnotacje(atrybuty). Dzięki czemu w łatwy sposób przekazuje się tylko te dane które są potrzebne, a nie całe klasy modelu.

NIe wypróżniamy się modelem domenowym na widok.
Model domenowy != model widoku

Rozbudujmy w takim razie poprzedni przykład
Załóżmy że klasa BankAccount zawiera także listę kart debetowych przypisanych do tego konta. I teraz mam dwa przypadki użycia: 1) wyświetlenie transakcji dla danego konta + numer konta, 2) wyświetlenie kart przypisanych dla danego konta + numer konta.
W repozytorium mam mieć jedną metodę GetBankAccount(int id) czy dwie które będą wykorzystywane w odpowiednich kontrolerach ?
Jak rozumiem Twoje podejście jest takie żeby zacząć od jednej, a gdy ewentualnie będzie to powodem problemów wydajnościowych to szukać optymalizacji ?

Czemu niby model będący projekcją faktycznych danych, miałby nie być zgodny ze stanem faktycznym?

Bo nie zawiera wszystkich danych. Np. dla przykładu powyżej BankAccount zwrócone do kontrolera wyświetlającego transakcje miałoby pustą listę kart.

Czytałem w książce a i nawet nam prowadzący o tym mówił żeby do widoków przekazywać tylko tyle danych ile jest potrzebnych.

NIe wypróżniamy się modelem domenowym na widok.

Ale moje pytanie nie dotyczyło ViewModeli i przekazywania danych do widoku.

dasdasfsdgfhfgd napisał(a):

Załóżmy że klasa BankAccount zawiera także listę kart debetowych przypisanych do tego konta. I teraz mam dwa przypadki użycia: 1) wyświetlenie transakcji dla danego konta + numer konta, 2) wyświetlenie kart przypisanych dla danego konta + numer konta.
W repozytorium mam mieć jedną metodę GetBankAccount(int id) czy dwie które będą wykorzystywane w odpowiednich kontrolerach ?

Tam, gdzie potrzebujesz wyświetlać konto + transakcje, pobierasz konto + transakcje, a w drugim przypadku konto + karty. Jeśli konta + transakcji + kart jednocześnie nie potrzebujesz nigdzie, to tego nie pobieraj.

Jak rozumiem Twoje podejście jest takie żeby zacząć od jednej, a gdy ewentualnie będzie to powodem problemów wydajnościowych to szukać optymalizacji ?

Chyba się nie zrozumieliśmy dokładnie. W pierwszym poście pytałeś o pobieranie danych z bazy. Jak zrozumiałem, że pytasz o to, czy encję wypełniać danymi z tabel w całości, czy tylko w potrzebnej części.

Generalnie mamy trzy warstwy:

1. Widok z ViewModelami
2. Domena z encjami
3. Baza danych z tabelami

Encje są mapowane do tabel 1:1, jeśli potrzebujesz danych z jakiegoś obiektu, to i tak pobierasz cały rekord z bazy, nie martwiąc się o to, że część kolumn pobierasz niepotrzebnie. Potem mapujesz encje na ViewModele, i tu już w zależności od potrzeb albo ustawiasz część właściwości, albo wszystkie, albo robisz jeden ViewModel z dwóch encji, itd.

Jeśli zaś pytasz o pobieranie z encją powiązanych encji, to jak już napisałem powyżej, pobieraj to, co rzeczywiście potrzebujesz. A jeśli korzystasz z ORM, pamiętaj o tym, żeby to pobrać zachłannie, żeby nie mieć problemu n+1.

Bo nie zawiera wszystkich danych. Np. dla przykładu powyżej BankAccount zwrócone do kontrolera wyświetlającego transakcje miałoby pustą listę kart.

Ale nie będziesz przecież wrzucał obiektu domenowego BankAccount do kontrolera, tylko do jednego kontrolera wyślesz BankAccountWithTransactionsViewModel, a do drugiego BankAccountWithCardsViewModel.