ASP.NET MVC 5 czy za każdym razem tworzyć ViewModel?

Witam,

Wziąłem się za naukę MVC 5 i mam małe pytanko.

Na początku korzystałem z darmowych kursów Plural Sight z asp.net, gdy dane z modelu były wystarczające do wyświetlenia tego co chcemy w View to były przekazane w return View(dane).

Jednak teraz uczę się z innego źródła i autor zaleca za każdym razem tworzyć ViewModel nawet jeśli dane nie wymagają łączenia dwóch klas modelowych.

Argumentuje to tym, że w przyszłości może się to przydać, jeśli będzie trzeba coś dodać do View.

Jest to jak najbardziej racjonalne, chciałbym się dowiedzieć jakie praktyki stosuje się w projektach, czy faktycznie zawsze tworzy się ViewModel?

W takim razie dlaczego MVC nazywa się MVC a nie MVVMC :D ?

Jak wiesz, że w przyszłości się zmieni, to możesz zrobić.
Jeżeli na modelu nie wykorzystujesz atrybutów, np. do walidacji, to też możesz z tego względu zrobić je na view modelu.
Jak ma być tylko żeby był, to nie ma to sensu.

Grzegorion napisał(a):

Jest to jak najbardziej racjonalne, chciałbym się dowiedzieć jakie praktyki stosuje się w projektach, czy faktycznie zawsze tworzy się ViewModel?

Słabi programiści nie, dobrzy tak.

Model to nie tylko dane, ale też zachowanie, cała logika biznesowa aplikacji.

W takim razie dlaczego MVC nazywa się MVC a nie MVVMC :D ?

Bo ViewModel jest nieistotny dla tej idei.

W dużych / rozwijających się projektach powinno stosować się ViewModel'e. Co prawda, z tym podejściem jest więcej zabawy przy mapowaniu obiektów widoku do typowego modelu bazy danych, natomiast rozwiązanie to jest na pewno bardziej elastyczne niż w przypadku stosowania tego samego modelu zarówno dla widoku jak i bazy danych.

somekind, gdzie twoim zdaniem powinny znaleźć się klasy typu ViewModels oraz klasy z dekoratorem [MetadataType(typeof(...))] ?

Zakładając, że moja aplikacja jest warstwowa (Web.ui, Serwis, Core i Data) - na najwyższym poziomie, tj. tam, gdzie aplikacja Web (UI), czy też na najniższym poziomie, tam, gdzie model i encje?

Grzegorion napisał(a):

W takim razie dlaczego MVC nazywa się MVC a nie MVVMC :D ?

Ponieważ VM (ViewModel) z MVC to zwykłe klasy typu DTO(DataTransferObject) implementowane zwykle jako POCO służące do przenoszenia informacji pomiędzy warstwami które są w relacji z warstwą prezentacji, co jak zostało zauważone jest mało istotnym szczegółem w MVC.

Krwawy Samiec napisał(a):

somekind, gdzie twoim zdaniem powinny znaleźć się klasy typu ViewModels oraz klasy z dekoratorem [MetadataType(typeof(...))] ?

Zakładając, że moja aplikacja jest warstwowa (Web.ui, Serwis, Core i Data) - na najwyższym poziomie, tj. tam, gdzie aplikacja Web (UI), czy też na najniższym poziomie, tam, gdzie model i encje?

Jak dla mnie, to ViewModele powinny być przesyłane między Serwisami aplikacyjnymi a kontrolerami, czyli być częścią Serwisów, chociaż ja bym wydzielił oddzielny moduł na kontrakty, do którego referencję miałyby Serwis i WebUI.

A klasy z MetadataType to chyba w koszu... Nie widzę raczej powodu, dla których miałbym ich używać. No, ale jeśli to zależy do czego ten metamodel jest potrzebny.

Dzięki za odpowiedź.

Do tej pory moje ViewModels realizowałem za pomocą klas, ale zastanowię się, czy rzeczywiście nie skorzystać z interfejsów.
Jeżeli chodzi o

MetadataType

to generalnie zależy mi na przejrzystości kodu, metadane "trzymam" w innej klasie/interfejsie, aczkolwiek nie wiem czy to nie jest przerost formy nad treścią.

Szczególnie problem robi się wtedy, gdy część metadanych chciałbym trzymać w specjalnej klasie/interfejsie stworzonych tylko w tym celu, a część metadanych trzeba wrzucić do ViewModels, żeby np. dobrze wyświetlić nazwy propercji w widoku. Brak tutaj konsekwencji z mojej strony i zastanawiam się co z tym zrobić.

Krwawy Samiec napisał(a):

Do tej pory moje ViewModels realizowałem za pomocą klas, ale zastanowię się, czy rzeczywiście nie skorzystać z interfejsów.

Tu chyba zaszło jakieś nieporozumienie, bo ja niczego takiego nie zasugerowałem. Chodziło mi jedynie o przeniesienie definicji klas ViewModeli do innego projektu/assembly.

Jeżeli chodzi o

MetadataType

to generalnie zależy mi na przejrzystości kodu, metadane "trzymam" w innej klasie/interfejsie, aczkolwiek nie wiem czy to nie jest przerost formy nad treścią.

No, ale czy to faktycznie jest bardziej przejrzyste? Moim zdaniem wręcz przeciwnie, bo jak chcę sprawdzić jakie są ograniczenia dla jakiegoś pola, to muszę skakać do innego pliku. Strata czasu moim zdaniem.

Tu chyba zaszło jakieś nieporozumienie, bo ja niczego takiego nie zasugerowałem. Chodziło mi jedynie o przeniesienie definicji klas ViewModeli do innego projektu/assembly.

A to przepraszam! Trochę nieopatrznie zrozumiałem sformułowanie "chociaż ja bym wydzielił oddzielny moduł na kontrakty" ;)

No, ale czy to faktycznie jest bardziej przejrzyste? Moim zdaniem wręcz przeciwnie, bo jak chcę sprawdzić jakie są ograniczenia dla jakiegoś pola, to muszę skakać do innego pliku. Strata czasu moim zdaniem.

OK. Dziękuję za profesjonalne odpowiedzi.