Czy do widoku powinienem przekazywać ViewModel?

Czy do widoku powinienem przekazywać ViewModel czy model w asp.net?

ViewModel jak sama nazwa wskazuje

Czyli ViewModel za każdym razem mam przekazywać do widoku? Tylko czy to wtedy będzie MVC?

Nie mam pojęcia, to zależy od tego, czy trzymasz się zasad MVC. Samo przekazywanie ViewModeli zamiast Modelu tego nie oznacza.

Tak ogólnie, to przecież już o to pytałeś tutaj

Tak pytałem. Tylko według tamtego tematu nie byłoby to MVC, wię chciałem się upewnić. Czyli więc jednak korzystanie z ViewModeli nie oznacza braku korzystania z MVC.

ViewModel uzywasz jak pomiedzy akcja j widokiem. Modelu uzywasz pomiedzy akcja i baza. Taka konwencja. To jest MVC.

Korzystanie z ViewModeli ani nie potwierdza ani nie zaprzecza zgodności z MVC. Tak samo jak nie robi tego korzystanie z pęli for albo bazy danych.

A można zamiast ViewModelu do widoku przekazywać encje?

Też można, tylko wtedy to jest "encja na twarz i pchasz", a nie MVC.

A czym się różni ViewModel od encji oprócz nazwy ? Czy do struktury bazy danych zawsze muszę używać struct zamiast class?

Zimny Mleczarz napisał(a):

A czym się różni ViewModel od encji oprócz nazwy ?

Tym, że reprezentuje to, co chcesz pokazać w GUI, a nie obiekt biznesowy z operacjami ani też obiekt służący do zapisywania w bazie danych.

Czy do struktury bazy danych zawsze muszę używać struct zamiast class?

Nigdy tak nie rób.

Nigdy tak nie rób.

Dlaczego?

Bo po pierwsze będzie niewydajne, po drugie pewnie nie ogarniesz debugowania tego, a po trzecie i najważniejsze - po co tak robić?

ViewModele i modele to tylko klasy. To co je odróżnia to fakt że pierwszy jest używany w widoku (jak sama nazwa wskazuje) natomiast drugi w logice biznesowej. Może się zdarzyć że zarówno model widoku jak j model biznesowy będą miały te same właściwości - w modelu widoku dodatkowo możesz również mieć np. atrybuty służące do walidacji. To jest coś czego nie chcesz miec w modelach biznesowych/domenowych, stąd potrzeba rozdzielenia tych koncepcji.

ViewModele i modele to tylko klasy. To co je odróżnia to fakt że pierwszy jest używany w widoku (jak sama nazwa wskazuje) natomiast drugi w logice biznesowej. Może się zdarzyć że zarówno model widoku jak j model biznesowy będą miały te same właściwości - w modelu widoku dodatkowo możesz również mieć np. atrybuty służące do walidacji. To jest coś czego nie chcesz miec w modelach biznesowych/domenowych, stąd potrzeba rozdzielenia tych koncepcji.

No ale tam pisze też model ---> ViewMODEL. Czyli ViewModel powinien też być używany w logice biznesowej...?

Nie, ViewModel to jest taki "zlepek" tego, co chcesz w danym momencie pokazać użytkownikowi.

Nie, ViewModel to jest taki "zlepek" tego, co chcesz w danym momencie pokazać użytkownikowi.

Czyli może zawierać politykę tego co chcę pokazać, co za tym idzie, część logiki biznesowej... Dlaczego wy mnie kłamiecie?. hehe ;)

"mnie kłamiecie" - w jakim to języku?

Nikt Cię nie oszukuje, po prostu złośliwie i uporczywie nie chcesz zrozumieć, że viewmodel ma nie zawierać żadnej logiki a jedynie dane.

Zimny Mleczarz napisał(a):

ViewModele i modele to tylko klasy. To co je odróżnia to fakt że pierwszy jest używany w widoku (jak sama nazwa wskazuje) natomiast drugi w logice biznesowej. Może się zdarzyć że zarówno model widoku jak j model biznesowy będą miały te same właściwości - w modelu widoku dodatkowo możesz również mieć np. atrybuty służące do walidacji. To jest coś czego nie chcesz miec w modelach biznesowych/domenowych, stąd potrzeba rozdzielenia tych koncepcji.

No ale tam pisze też model ---> ViewMODEL. Czyli ViewModel powinien też być używany w logice biznesowej...?

A co ma słowo model do logiki biznesowej? Lepiej nie kupuj żadnego telefonu. Sprzedawca spyta Cie jaki model Cie interesuje a Ty wyskoczysz z tekstem że przecież to telefon a nie logika biznesowa więc co on Ci z jakimiś modelami wyjeżdża.

Nikt Cię nie oszukuje, po prostu złośliwie i uporczywie nie chcesz zrozumieć, że viewmodel ma nie zawierać żadnej logiki a jedynie dane.

Chodzi mi o to, że nie widzę nic złego w dodaniu attrybutów do ViewModel lub użyciu ViewModelu w delegacie aby zakreślić jakąś regułe. Chodzi mi o ogólne wykorzystanie metadanych ViewModelu do wpływania na zachowanie logiki "biznesowej", Jak ma to miejscę np. w PizzyFramework.

Orkeślenie ViewModelu jako zlepek tego co chcesz pokazać to moim zdaniem słaby pomysł. ;)

A co ma słowo model do logiki biznesowej? Lepiej nie kupuj żadnego telefonu. Sprzedawca spyta Cie jaki model Cie interesuje a Ty wyskoczysz z tekstem że przecież to telefon a nie logika biznesowa więc co on Ci z jakimiś modelami wyjeżdża.

Haha,

Ja mam inaczej. Jak zamawiam pokój w hotelu to mówie z modelem widoku na morze, żeby czasem się nie okazało, że zamówiłem pokój bez okien. hahahah.... No bo bez modelu to i widoku by nie było.

Zimny Mleczarz napisał(a):

Chodzi mi o to, że nie widzę nic złego w dodaniu attrybutów do ViewModel lub użyciu ViewModelu w delegacie aby zakreślić jakąś regułe. Chodzi mi o ogólne wykorzystanie metadanych ViewModelu do wpływania na zachowanie logiki "biznesowej"

Ale jakie reguły, jaką logikę biznesową? Wyłączanie edycji, wyświetlanie w trybie tylko do odczytu, wybór kontrolki użytej do edycji to wszystko jest logika prezentacji, a nie biznesowa. Walidacja inputu to też nie jest logika biznesowa.

Orkeślenie ViewModelu jako zlepek tego co chcesz pokazać to moim zdaniem słaby pomysł. ;)

To określaj sobie inaczej, możesz nawet prowadzić prelekcje o tym w ramach jakiegoś freak show.

Ale jakie reguły, jaką logikę biznesową? Wyłączanie edycji, wyświetlanie w trybie tylko do odczytu, wybór kontrolki użytej do edycji to wszystko jest logika prezentacji, a nie biznesowa. Walidacja inputu to też nie jest logika biznesowa.

A to że klient aplikacji chce wyświetlić cene produktu, lub grupować, oraz sortować produkty to są wymagania biznesu czy samej aplikacji.?

Z czym ty w oglóle znowu wyjeżdzasz, mnie nie chodzi o wybór kontrolek, tylko ich określenie z nie wielką pomocą spójnego obiektu jakim jest ViewModel.

Jak masz kwadratową głowę od pisania struktury w stulu 5 serwisów dlatego, że akurat każdy używa innej kontrolki to twój problem. Widzę, że znowu na siłe starasz się przekonać innych do tego, że masz rację.

Chodzi mi o logikę powiązaną z tymi kontrolkami. W stylu co się stanie jeśli Fillter.Like

Chodzi o to że metadanymi z VM. Możesz wpływać na działanie logiki związanej z pobieraniem danych tak samo jak na ich wyświetlanie w logice widoku. Dlatego to się nazywa VM i jest ogniwem łączącym jedno z drugim.

Zimny Mleczarz napisał(a):

A to że klient aplikacji chce wyświetlić cene produktu, lub grupować, oraz sortować produkty to są wymagania biznesu czy samej aplikacji.?

Biznesu, tylko jaki to ma związek z dyskusją? Czy viewmodel odpowiada za grupowanie i sortowanie? Bo viewmodel to bierny pojemnik na dane, struktura która jest przekazywana z warstw wewnętrznych do do wyświetlenia w warstwie prezentacji.

Z czym ty w oglóle znowu wyjeżdzasz, mnie nie chodzi o wybór kontrolek, tylko ich określenie z nie wielką pomocą spójnego obiektu jakim jest ViewModel.

No i to jest właśnie logika prezentacji.

Widzę, że znowu na siłe starasz się przekonać innych do tego, że masz rację.

Nie muszę nikogo przekonywać, tak po prostu jest, bo taka jest rzeczywistość. Nie chcesz - nie akceptuj i wracaj do swojego cyrku.

PS. Czemu nie piszesz z konta?

No ale przecież samo WPF czy ASP. Nie udostępnia takich atrubutów dlatego oczywiście, jeszcze nikt nie wpad na taki pomysł no bo to jest za trudne dla większości forumowiczów.

PS. Czemu nie piszesz z konta?

Ponieważ mam do tego prawo.

Biznesu, tylko jaki to ma związek z dyskusją? Czy viewmodel odpowiada za grupowanie i sortowanie? Bo viewmodel to bierny pojemnik na dane, struktura która jest przekazywana z warstw wewnętrznych do do wyświetlenia w warstwie prezentacji.

No to widoczne jeszcze nie odkyłeś tego, że za pomocą metadanych VM i Pewsistance możesz generować zapytania do bazy dynamicznie.

Z wykorzystaniem odpowiedniego algorytmu, który będzie te metadane przetwarzał.

Zimny Mleczarz napisał(a):

No ale przecież samo WPF czy ASP. Nie udostępnia takich atrubutów dlatego oczywiście, jeszcze nikt nie wpad na taki pomysł no bo to jest za trudne dla większości forumowiczów.

A co ma rzekoma trudność dla forumowiczów do ogólnie przyjętych na świecie wzorców? :)

No to widoczne jeszcze nie odkyłeś tego, że za pomocą metadanych VM i Pewsistance możesz generować zapytania do bazy dynamicznie.

Oczywiście, nie wpadłem. Tak sobie tłumacz. :D :D :D
Automatyczne generowanie zapytań do bazy na podstawie viewmodeli nie zmienia faktu, że viewmodel to pojemnik na dane do wyświetlenia.