Archief - MVC, gebruik van ViewModels

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

nck2040

Legacy Member
Momenteel met een MVC project bezig en we hebben bij een vorig project enkel gebruik gemaakt van Models en Views. Maar heb gehoord dat we ook beter nog met ViewModels zouden werken. Ik begrijp enkel niet zo goed wat de voordelen hiervan zijn. Heb al wat opgezocht zoals bv. op verschillende manieren een pagina manipuleren en het zou ook beter voor het geheugen zijn?

Kan iemand misschien even duidelijk het nut van ViewModels uitleggen?

Curahee Q

Legacy Member
ViewModels worden gebruikt om je model (domein) nog verder af te schermen van je view waardoor de koppeling tussen beide losser is.

Je bouwt je ViewModel op basis van hetgeen je nodig hebt in de View. Dus je kijkt bij het bouwen van je ViewModel nog niet naar je Model zelf.

Stel dat je alle klanten wilt tonen op je webpagina. Met hun voornaam, familienaam en e-mail adres. Dit is hetgeen je nodig hebt in je View.

Code:
public class CustomerViewModel
{
	public string FirstName { get; private set; }
	public string LastName { get; private set; }
	public string Email { get; private set; }

	public CustomerViewModel(Customer customer) {
		this.FirstName = customer.FirstName;
		this.LastName = customer.LastName;
		this.Email = customer.Email;
	}
}

Als je dit nu meegeeft naar je View kan je dus de firstname, lastname, en email opvragen van de klant.

Waarom niet gewoon het customer object doorgeven?
Het customer object kan nog veel properties hebben die de view niet nodig heeft. De view kan dan tevens ook gewoon waarden van de customer gaan wijzigen.
Wanneer er iets veranderd in je model van je customer moet je niets wijzigen in je view. Stel dat er 5 views zijn die het customer object nodig hebben en je beslist om in je model de firstname en lastname samen te voegen, dan moet je al je views gaan aanpassen. Anders kan je gewoon in je ViewModel zeggen

Code:
public class CustomerViewModel
{
	public string FirstName { get; private set; }
	public string LastName { get; private set; }
	public string Email { get; private set; }

	public CustomerViewModel(Customer customer) {
		string[] split = customer.Split(' ');
	
		this.FirstName = split[0];
		this.LastName = split[1];
		this.Email = customer.Email;
	}
}

Het is maar een simpel voorbeeld maar ik hoop dat je hiermee het grotere beeld ziet van wat de voordelen er van zijn.

SideShow

Legacy Member
Ik ben momenteel bezig met een viewmodel voor een zoekmachine.

Er wordt van de blob aan data (een "zoekresultaten-object") een klein viewmodel gemaakt.

Een lijstcontrol in de user interface wordt opgebouwd adhv dit viewmodel en heeft van de complete datablob geen weet.

Maar "MVC" met viewmodels, is dat niet MVVM dan?

Ik gebruik momenteel http://knockoutjs.com/
Dit werkt heel mooi dmv je client side GUI aan je viewmodel te binden met minimal effort.
Het gootste voordeel van knockout is echter dat de bindings volledig automatisch gebeuren en daarbovenop een betrekkelijk overzichtlijk templatingsysteem biedt.

Dit naast je vraag van een viewmodel. Je kan het letterlijk interpreteren: het is een view(ke) op een groter of complex model/object, dat wordt gebruikt om front-end/gui mee op te bouwen.
Je zou het zelfs kunnen gebruiken al een soort van contract/interface tussen de echte modellen en de front-end controls, net zoals je interfaces/contracten kan zetten tussen bijvoorbeeld front-end laag en business laag.

NeverwinterX

Legacy Member
Curahee Q zei:
Wanneer er iets veranderd in je model van je customer moet je niets wijzigen in je view. Stel dat er 5 views zijn die het customer object nodig hebben en je beslist om in je model de firstname en lastname samen te voegen, dan moet je al je views gaan aanpassen. Anders kan je gewoon in je ViewModel zeggen.

In realiteit zal een echte verandering aan je object model (niet een kleine gedragsverandering) voor een verandering aan uw viewmodel zorgen wat dan ook voor een verandering zorgt op uw view. (wat meestal sowieso nodig is in zo'n geval: je wilt namelijk wat je toevoegt/wijzigt toch ook tonen in uw view). Voor gevallen waar ge het netjes op kunt lossen zoals het voorbeeld van voornaam en achternaam moet je al geluk hebben. Dat soort doorgedreven scheiding zorgt alleen maar voor meer indirectie lagen die je moet wijzigen bij echte veranderingen en geven een illusie van scheiding.
De enige scheiding die er echt toe doet in de 101 MVC modellen is dat uw business code niks van gui rechtstreeks mag aanroepen. Dat is de enige richtlijn die u echt werk zal besparen.

Cycloon

Legacy Member
Eigenlijk moet een viewmodel vooral ten dienste zijn van de view. Het moet eenvoudig zijn voor de view om de nodige data ergens te halen, onafhankelijk van hoe die data ergens in een model zit verwerkt. Ik denk bv. aan iets banaals als je moet een aantal stuks laten zien. Bij 1 stuk moet er enkelvoud staan, bij meerdere uiteraard meervoud. Die string opbouwen is typisch iets dat in je viewmodel komt te staan. Maar het gaat verder dan enkel data uit je model transformeren om je view te voorzien. Het viewmodel kan ook enorm goed gebruikt worden om bepaalde staten te bewaren en user interactie eenvoudiger te verwerken. Dit laatste wordt vaak wel eens over het hoofd gezien.

Een énorm mooi voorbeeld is Simplifying the WPF TreeView by Using the ViewModel Pattern - CodeProject . Het is zeker de moeite waard om deze te lezen, ook al gebruik je zelf geen WPF. De concepten kunnen overal toegepast worden.

Moto

Legacy Member
Dit is eigenlijk vrij simpel,

Dus MVC / MVVM zijn Design Patterns.
Design Patterns zijn er dus om veelvoorkomende complexe problemen op een simpele/overzichtelijke manier op te lossen

Dus ten eerste moeten we een complex probleem hebben, was het vorige project waar enkel models en views werden gebruikt te complex?
Ik veronderstel van wel omdat we nu een ander uitgebreider design pattern gaan willen gebruiken.
Als ge dus ervaring hebt met het vorig project dat te complex was moet een simpele tutorial van het nieuwe design pattern toch direkt zijn voordelen kunnen duidelijk maken aan U.

Waarom zou ge het anders gaan gebruiken?
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan