Sorki za nazwę tematu ;)
Rzecz ma się tak
mam klasę User, która ma wiele powiązań, np:
Messages,
UserDetails,
Interests,
CokolwiekInnego,
Friends
oraz wiele właściwości prostych
używam EF Core 2.0 gdzie lazyloading jeszcze nie istnieje, ale w dao mam możliwość dołączania odpowiednich tabel.
np. w przypadku gdy będą mniej interesować UserDetails, mogę w UsersDao stworzyc metodę
QueryUserWithDetals(..)
{
_dbContext.Users.Include(u=>u.UserDetails)
}
w przypadku messages, adekwatnie:
QueryUsersWithMessages()
{
_dbContext.Users.Include(u=>u.Messages)
}
w przypadku chęci wykorzystania wielu dowiązań można naraz pobrać i users i messages (ale to akurat bezsensowy przykład)
Tworzę Web-Api, więc to klient w zakłądce wiadomości będzie pośrednio wołał o QueryUsersWithMessages, zaś wyszukiwarka użytkowników będzie pośrednio wołała do QueryUserWithDetals
zwracane tak czy siak jest zawsze jakieś DTO (np. usersDto będzie miało już tablicę [FriendsDto]) - ale uzupełnianie danych w tym dto będzie zawsze zależało od kontekstu - znowu - w wiadomościach użytkownika nie będą mnie interesowały szczegółowe informacje dot. użytkowinka, jak np. numer buta
A więc... czy jest w ogóle sens w klasie User dać Messages, UserDetails, itd.?
Czy nie lepiej to bardziej rozdzielić na serwisy:
UsersDetailsService, UsersService, MessagesService, FriendsService
a API tak czy siak będzie wołało odpowiedni serwis, np. w zapytaniu o "znajomych" zapyta FriendsService,
a ten z kolei zada pytanie do bazy:
UsersFriends.Where(x=> x.user1Id == queryId || x.user2Id == queryId)
Więc tu nachodzi mnie pytanie : po co w ogóle na poziomie klasy USER dawać "odnośniki" do innych powiązanych obiektów,
skoro zawsze można odpytać konkretną tabelę
Jedynym atutem posiadania w klasie User pola Messages jest odwołanie się do wiadomości Usera przez userEntity.Messages
Troszkę zagmatwałem, ale w sumie robić tak, że User zawiera Messages, Details, itd, czy starać się je izolować (bo co mnie obchodzą Messages usera, kiedy jestem na poziomie Users.Friends)
Od czego to zależy?
Podejrzewam że w aplikacjach okienkowych, czy raczej tam, gdzie cały czas jest zapewniony dostęp do bazy (czyli np. zmieniamy nazwisko usera, a po opuszczeniu textboxa to się od razu aktualizuje) wykorzysta się raczej user.Details, user.Friends, a zaś w WEBie, a przede wszystkim w Web api, gdzie klient za każdym razem odpytuje api (za każdym przekliknięciem zakładki) lepiej jest mieć oddzielnie te klasy, niepowiązane z sobą?