Jeśli robię aplikację przy użyciu asp.net mvc, ale do tego jeszcze mam view modele to czy nadal jest to wzorzec MVC?
0
0
Jak najbardziej.
1
Albo i nie bo " robię aplikację przy użyciu asp.net mvc" wcale nie oznacza że "jest to wzorzec MVC" :)
2
Zimny Kaczor3 napisał(a):
Jeśli robię aplikację przy użyciu asp.net mvc, ale do tego jeszcze mam view modele to czy nadal jest to wzorzec MVC?
Skoro zadajesz takie pytanie, to raczej nie. Bo ViewModel to tylko twór pomocniczy służący do wymiany danych między kontrolerem a widokiem, a model to logika aplikacji.
0
To jak ten wzorzec wtedy nazwac? Niektórych rzeczy w asp.net mvc bez viewmodeli ciężko zrobić. Chociażby do rejestracji wykorzystuje pomocniczy viewmodel.
0
Ok, to jeszcze raz:
- Uźywanie albo nieużywanie viewmodeli nie ma nic do MVC.
- To, że używasz ASP.NET MVC nie znaczy, że Twoja aplikacja jest zgodna z wzorcem MVC. Framework ułatwia tworzenie zgodnie z tym wzorcem, ale jeśli np. podążasz zgodnie z większością dostępnych w necie materiałów i umieszczasz logikę aplikacji i repozytoria w kontrolerach, to to nie jest MVC.
0
Jeśli umieszczam logikę aplikacji w kontrolerach to nie jest MVC? To gzie ją umieszczać?
0
Ale w modelu przecież nie będę pobierać danych z bazy. To raczej w kontrolerze się robi - jak dla mnie to jest część logiki aplikacji.
1
Nie, to w Modelu pobiera się dane z bazy. W Modelu przeprowadza się obliczenia i wykonuje wszelką inną logikę biznesową. Kontroler ma tylko pobrać żądanie od użytkownika, a następnie przekazać do wykonania w Modelu.
0
We wszystkich projektach jakich widziałem w kontrolerach jest to robione.
1
Pewnie mówisz o tutorialach które mają na celu pokazanie zasadę działania asp mvc. Ale poważnych projektach tak się tego nie robi. Pomyśl tak. Robisz aplikację webową z jakąś logiką (wszystko w kontrolerach) i potrzebujesz dorzucić do tego jakieś API które by korzystało z tej logiki. I co kopiować całą logikę do Api? Ja robię tak że: Tworzę klasy tzw serviców które zawierają logikę, operują na modelach, korzystają z DBContextu w celu pobrania, zapisania zmian. A kontrolery tylko wywołują metody w servicach. To jest pewnie dalekie od ideału ale lepsze niż "tłuste kontroleryt"
1
Zimny Kaczor3 napisał(a):
We wszystkich projektach jakich widziałem w kontrolerach jest to robione.
Więc te projekty nie implementują wzorca MVC.
2
Ech. A ludzie nie lubią jak na studiach uczą jakieś programy do obliczeń funkcji pisać. A moze ma to sens bo uczy pisać program bez UI. I może da sie napisać prawie caly program bez UI a pierwszym UI bedzie projekt z testami a potem to podłączamy do winforms, mvc czy czegokolwiek. To znaczy do winforms :)
0
Ja bym nie był taki rygorystyczny i bardziej ostrożny w stwierdzeniach co jest, a co nie jest MVC. Bo niestety jeśli chodzi o te wzorce wyższego poziomu, to świat nie jest czarno biały, i one są zwykle dość luźno opisane, pozostawiając spore pole do różnych interpretacji/implementacji i polemiki.
W szczególności czym jest to M w MVC :), bo jeśli MVC zinterpretujemy jako wyłącznie wzorzec prezentacji, to pod naszym M tak naprawdę kryją się nasze view modele(nazywane modelami), a kontroler jest odpowiedzialny za ich przygotowanie dla widoków. W takiej interpretacji w ogóle nie ma ani słowa o logice biznesowej, ani skąd ją kontroler ma i gdzie powinna być. Pamiętam pierwsze bety asp.net mvc, i w dokumentach które Microsoft publikował wnikało że właśnie taką interpretację mieli na myśli. Ba, oryginalny wzorzec MVC z Smalltalk z lat 80 też byłą wyłącznie wzorcem dla GUI, jeśli wierzyć różnym historią które można znaleźć w internecie, bo przecież oryginalnej definicji nie ma, są tylko legendy.
Obecnie w oficjalny materiałach od Microsoftu, MVC jest zwykle przedstawiany jako wzorzec architektury, gdzie M jest interpretowane jako model domenowy.
Co nie zmienia faktu że sprawa jest śliska, tak samo jak z Repozytorium, które w różnych kontekstach znaczy co innego.
2
neves napisał(a):
Ja bym nie był taki rygorystyczny i bardziej ostrożny w stwierdzeniach co jest, a co nie jest MVC. Bo niestety jeśli chodzi o te wzorce wyższego poziomu, to świat nie jest czarno biały, i one są zwykle dość luźno opisane, pozostawiając spore pole do różnych interpretacji/implementacji i polemiki.
Gdzie są luźno opisane? Chyba w słabych tutorialach, bo nie w oryginalnych materiałach czy sensownych stronach.
W szczególności czym jest to M w MVC :), bo jeśli MVC zinterpretujemy jako wyłącznie wzorzec prezentacji, to pod naszym M tak naprawdę kryją się nasze view modele(nazywane modelami), a kontroler jest odpowiedzialny za ich przygotowanie dla widoków. W takiej interpretacji w ogóle nie ma ani słowa o logice biznesowej, ani skąd ją kontroler ma i gdzie powinna być.
Tylko czemu interpretować defincje po swojemu? Trzeba albo nie znać języka albo być szalonym.
No i jeśli nawet logiki nie umieścilibyśmy w Modelu, to gdzie? Bo na pewno nie w Kontrolerach - bo każda definicja MVC jasno mówi, że ich zadaniem jest sterowanie Widokami i interakcja z użytkownikiem.
Ba, oryginalny wzorzec MVC z Smalltalk z lat 80 też byłą wyłącznie wzorcem dla GUI, jeśli wierzyć różnym historią które można znaleźć w internecie, bo przecież oryginalnej definicji nie ma, są tylko legendy.
Tego oryginału nie ma?
http://heim.ifi.uio.no/~trygver/2007/MVC_Originals.pdf
To wszystko jest bardzo, bardzo proste. Aplikacje tworzymy w celu zamodelowania jakiejś części otaczającego świata. Aplikacja poza tym musi też zawierać elementy pozwalające na interakcję użytkownika, łączność z innymi systemami, źródłami danych, autodiagnostykę, i wiele innych. Ale ta główna część, której celem jest modelowanie nazywa się Model.
0
somekind napisał(a):
Tylko czemu interpretować defincje po swojemu? Trzeba albo nie znać języka albo być szalonym.
No i jeśli nawet logiki nie umieścilibyśmy w Modelu, to gdzie? Bo na pewno nie w Kontrolerach - bo każda definicja MVC jasno mówi, że ich zadaniem jest sterowanie Widokami i interakcja z użytkownikiem.
W interpretacji MVC jako wzorca prezentacji, logika powinna być poza nim, a że framework tego nie wymusza w żaden sposób, to ludzie idą po linii najmniejszego oporu i pada na kontrolery. Zresztą gdyby każda definicja była jasna i łatwo dostępna to by nie popowstawały ośmiotysięczniki w kontrolerach i inne straszne rzeczy. Ale to nie matematyka, tylko inżynieria oprogramowania, i pole do (nad)interpretacji jest naprawdę spore.
somekind napisał(a):
Tego oryginału nie ma?
http://heim.ifi.uio.no/~trygver/2007/MVC_Originals.pdf
A jednak istnieje :)! i opisuje MVC w wersji znanej dzisiaj jako aktywne MVC, które zostało zinterpretowane i dostosowane do kontekstu weba jako mvc bodaj model 2 w świecie javy czy też bodaj mvc pasywne w ogólności....
0
ale nawet taka logika do asp.net identity jest w kontrolerach. To co jeśli używamy asp.net identity to już nie używamy wzorca MVC ;p?
1
Ale jaka logika identity jest w kontrolerach?
0
Wielki Krawiec napisał(a):
ale nawet taka logika do asp.net identity jest w kontrolerach. To co jeśli używamy asp.net identity to już nie używamy wzorca MVC ;p?
Niby czemu? Autoryzacja i uwierzytelnianie nie są związane z dziedziną problemu, którą reprezentuje Model. To jest infrastruktura, a nie dziedzina aplikacji.
Druga sprawa - czemu robić to w kontrolerach, od tego są atrybuty.
0
[somekind napisał(a)]):
Wielki Krawiec napisał(a):
ale nawet taka logika do asp.net identity jest w kontrolerach. To co jeśli używamy asp.net identity to już nie używamy wzorca MVC ;p?
Niby czemu? Autoryzacja i uwierzytelnianie nie są związane z dziedziną problemu, którą reprezentuje Model. To jest infrastruktura, a nie dziedzina aplikacji.
Druga sprawa - czemu robić to w kontrolerach, od tego są atrybuty.
Role użytkowników, jak najbardziej mogą być związane z dziedziną problemu.
0
Owszem, w systemie (albo raczej module większego systemu) przeznaczonym do zarządzania użytkownikami i ich rolami, a nie do uwierzytelniania i autoryzacji jakiejś operacji wykonywanej przez użytkownika ogólnie.
0
Chyba chciałeś powiedzieć w kontekście autoryzacji jakiegoś systemu. Masz rację, widok powinien konsumować obiekt z infrastrukturę w celu sprawdzenia stanu roli user'a i tp. Gdy słyszę autoryzacja widzę bardziej to jako kontekst a nie oddzielną część.