Czy dla każdego modelu ustawiać IoC?
Gdy np. w jednym kontrolerze chcę z kontekstu zaczerpnąć tylko dwie nie powiązane ze sobą tabelki to czemu by nie trzymać kontekstu w kontrolerze?
Dlaczego powinno się to stosować? Czy zawsze wykorzystujecie IoC? Oraz Repozytorium(przeniesienie modeli do innego projektu)?
Jak przekazać dane do widoku?
Wysyłam return View(context.Tabela.AsNoTracking()); czy to dobre rozwiązanie?
Mam jeszcze wiele pytań. Lecz na początek to ;)
W kontrolerach nie powinno się korzystać z kontekstów (zakładam, że chodzi Ci o DbContext z EF).
Zazwyczaj w każdej aplikacji większej niż hello world, dobrze jest używać IoC. I jeśli się go używa, to wypada robić to w całości aplikacji, a nie tylko w kawałku.
Repozytorium to nie jest przeniesienie modeli do innego projektu tylko źródło danych dla logiki biznesowej, typowe dla podejścia DDD. A z punktu widzenia MVC, zarówno logika biznesowa, jak i repozytoria, to Model.
Do widoków zaś powinno przesyłać się ViewModele zawierające tylko te dane, które są na widoku potrzebne, a nie encje bazodanowe. W ogóle aplikacja webowa nie powinna być świadoma istnienia EF.
Dzięki za odpowiedź.
To w takim razie jak sprawdzić by aplikacja nie była świadoma połączenia z EF?
Poprzez ViewModele rozumiesz widoki typowane? Czyli te które zawierają np.
@model IEnumerable<Model>
oraz "dane" przesyłane są do nich za pomocą return View z akcji kontrolera?
W takim razie jak przesłać "dobrze" te dane?
skoro w przykładowo startowym projekcie MVC w akcji About z kontrolera Home wysyłamy tak:
retrun View(context.Tabela.ToList();
i jest to "nie poprawnie"?
Mam jeszcze takie pytanie.
W kontrolerze Home mam akcje About i Index w każdym widoku tej akcji będą wyświetlane inne tabele z tego samego kontekstu.
W związku z tym rozbić to na 2 kontrolery z czego każdy operuje na innej tabeli czy umieścić to w jednym kontrolerze ale wyświetlanie danych wstawić jako partial z innego kontrolera i akcji np.
@ActionLink("Tabela 1", "Home/Index");
@ActionLink("Tabela 2", "Kontroler 2/Index");
Piszę sklep internetowy i chcę to zrobić od początku "w miarę" dobrze by późniejsza modyfikacja była przyjemniejsza.
dodanie znaczników <code class="csharp"> - @furious programming
Włóczykijek napisał(a):
To w takim razie jak sprawdzić by aplikacja nie była świadoma połączenia z EF?
Dzieląc na warstwy. Podziel aplikację na dwa projekty:
Web - aplikacja MVC
Services - logika aplikacji
Kontrolery MVC nie wykonują żadnej logiki, tylko wołają Serwisy. Serwisy operują na kontekście i encjach bazodanowych, a do MVC zwracają odpowiednie ViewModele. (W tym podejściu tylko Serwisy wiedzą o EF.)
Możesz to sobie bardziej skomplikować, np. dodać repozytoria (jako interfejsy w Serwisach) i nowy projekt DataLayer, w którym będą ich implementacje. (W tym podejściu tylko DataLayer wie o EF.)
Poprzez ViewModele rozumiesz widoki typowane? Czyli te które zawierają np.
ViewModel to klasa zawierająca dane pokazywane użytkownikowi na interfejsie. To powinny być inne klasy niż encje bazodanowe.
I owszem, to są te klasy, które używasz w widokach za pomocą dyrektywy @model.
skoro w przykładowo startowym projekcie MVC w akcji About z kontrolera Home wysyłamy tak:
retrun View(context.Tabela.ToList();
i jest to "nie poprawnie"?
Bo startowy projekt MVC przedstawia schemat działania frameworka MVC, a nie sensowną architekturę aplikacji.
Generalnie wszystkie tutoriale Microsoftu dotyczące ASP.NET MVC są niezgodne ze wzorcem MVC, bo pokazują logikę biznesową i operacje na źródle danych realizowane przez kontrolery. Tymczasem takie rzeczy powinny być realizowane przez model, a kontrolery powinny jedynie pośredniczyć między żądaniami użytkownika, a modelem. Ich logika jest bardzo prosta, np. decydują który widok wyświetlić, albo którą metodę z modelu wywołać.
Mam jeszcze takie pytanie.
W kontrolerze Home mam akcje About i Index w każdym widoku tej akcji będą wyświetlane inne tabele z tego samego kontekstu.
W związku z tym rozbić to na 2 kontrolery z czego każdy operuje na innej tabeli czy umieścić to w jednym kontrolerze ale wyświetlanie danych wstawić jako partial z innego kontrolera i akcji np.
Trudno powiedzieć, bo za mało szczegółów podałeś. Partiale służą do definiowania wizualnych komponentów, które można używać w kilku miejscach aplikacji. Jeśli nie potrzebujesz takiej możliwości, to chyba nie ma sensu tworzenie partiali. Kontrolery zazwyczaj wiąże się z widokami i akcjami dotyczącymi realizowania jakiegoś jednego przypadku biznesowego, nie jest ważne ile tabel jest do tego potrzebnych.
Dzięki za ciekawą odpowiedź. Zabieram się za przebudowę aplikacji.
Znasz może jakiś przykład prawidłowo zbudowanej aplikacji MVC? Wykorzystującej właśnie ten podział na osobny projekt dla logiki?
Mówisz, żeby nie operować w widokach typowanych na klasach encji(np. z podejścia Code First(modele)) więc operować z widoków na nich za pomocą interfejsu?
Aby dobrze to zrobić to gdzie umieścić ten interfejs? Czy może zamiast bezpośredniego wciskania interfejsów wstrzykiwać w jego miejsce klasy poprzez wstrzykiwanie zależności?
Włóczykijek napisał(a):
Znasz może jakiś przykład prawidłowo zbudowanej aplikacji MVC?
Nie bardzo.
Wykorzystującej właśnie ten podział na osobny projekt dla logiki?
A to to chyba nie jest problem. Dodajesz do solucji nowy projekt typu DLL library i wio.
Mówisz, żeby nie operować w widokach typowanych na klasach encji(np. z podejścia Code First(modele)) więc operować z widoków na nich za pomocą interfejsu?
Widok w ogóle nie powinien na niczym operować, on tylko dostaje obiekt (albo ich kolekcję) do wyświetlenia.
Czy może zamiast bezpośredniego wciskania interfejsów wstrzykiwać w jego miejsce klasy poprzez wstrzykiwanie zależności?
No żeby coś zrobić trzeba użyć klasy, interfejsy przecież nie posaidają implementacji.