@somekind fajna ta odpowiedź, taka nie za miła :)
Czy Ty masz do mnie pretensje, że Ci powiedziałem, że autor artykułu nie ma pojęcia o czym pisze, czym wprowadza Ciebie w błąd?
Jak dla mnie, to możesz podążać za jego naukami, tylko chyba sam już widzisz, że coś z nimi jest nie tak, skoro Ci nie pomagają.
W takim razie równie dobrze moglibyśmy rozmawiać o negowaniu tego, że Ziemia jest okrągła.
Nie bardzo rozumiem jak się to ma do konieczności weryfikowania wszelkich informacji w wielu źródłach ani skąd pomysł na taki przykład.
Kształt ziemi jest udowodniony naukowo, w przypadku inżynierii nie mamy dowodów naukowych, przy konstruowaniu czegoś wspieramy się oczywiście nauką, tam gdzie da się ją zastosować, ale bazujemy na intuicji i doświadczeniu. Dlatego jeśli ktoś mówi, żeby robić coś w jakiś sposób, to warto sprawdzić jakie ten sposób ma wady i wysłuchać/poczytać przeciwników danego podejścia.
Generalnie pierwszych kilkanaście wyników z Google na jakiś temat, to często kopiuj-wklej z jednego źródła, więc promowane jest to samo podejście (często nieprawidłowe) i powtarzane są te same błędy. Dlatego warto czasem spojrzeć dalej.
Masz na myśli jakieś konkretne przykłady? W moim przypadku chodzi o jedno - odseparowanie danych modelu od encji, jeśli jesteś w stanie odpowiedzieć jak mogę to zrobić w moim projekcie, bez zbędnych dogryzek - będę wdzięczny.
Myślę, że już powiedziałem kilka razy. :) Obiekty, które zapisujesz do bazy i obiekty, które przesyłasz między kontrolerem a widokiem, to dwa zupełnie odmienne zestawy obiektów. No i tyle, trzeba ten kod po prostu napisać.
Jeśli Twoje encje to Book i Author połączone powiązaniem (nie żadną relacją) wiele do wielu, to (robiąc typowego cruda) potrzebujesz zapewne co najmniej takich viewmodeli:
- BookListViewModel - tytuł, nazwiska kilku pierwszych autorów, data wydania
- AutorListViewModel - imię, nazwisko, data urodzenia i inne rzeczy to wyświetlenia na liście
- AuthorEditViewModel - w sumie to co powyżej
- BookEditViewModel - tytuł, data wydania, ISBN, lista par ID - imię i nazwisko autora (do wypełnienia comboboxa), lista ID autorów (tych wybranych przez użytkownika).
To co jest na widoku nie wygląda jak to, co jest w bazie, więc w kodzie też musi to wyglądać inaczej.
Jak widzicie w obu przykładach dla modeli wołam o kolekcję BookModel lub AuthorModel.
I to jest chyba podstawowy błąd. Do czego potrzebne Ci te kolekcje?
- Tworzysz gdzieś zagnieżdżone widoki? Jeśli tak, to prawdopodobnie powinieneś pobierać dane do widoku zewnętrznego i wewnętrznego oddzielnie.
- Potrzebujesz listy autorów do zbudowania comboboxa do edycji książki? Nie, wystarczy lista par ID-Imię i nazwisko.
- Budujesz API zwracające cały graf z bazy? To wtedy to nie są modele. :)
Cykliczne referencje w tych modelach też nie wróżą nic dobrego.
Ok i teraz dalej. Mam repo, które implementuje interfejs
A po co Ci to repozytorium w ogóle? Serwis może korzystać z LibraryContext
i zwracać modele.
@model Application.Models.BookModel
<h1>Informacje o książce</h1>
<p>
<h2>Tytuł: @Model.Title</h2>
<h3>
Imię i nazwisko autora:
@foreach (var author in Model.Authors)
{
@author.FirstName @author.SecondName
}
</h3>
<h3>Numer ISBN: @Model.ISBN</h3>
<h3>Wydawnictwo: @Model.PublishingHouse</h3>
<h3>Liczba stron: @Model.NumberOfPages</h3>
</p>
No i zobacz - Twój AuthorModel
ma 5 właściwości, z czego jedna jest kolekcją BookModel
. Ty używasz tylko dwóch. To po co pozostałe?
BTW, @WeiXiao: Ty jesteś ekspertem od niepełnosprawnych ORMów, serio teraz trzeba tak pisać: _context.Books.Include(a => a.Authors).Include("Authors.Author").Single(b => b.Id == id)
?