1. #1

    Registered
    03/02/04
    Location
    Hever
    Posts
    916
    iTrader
    47 (100%)
    Mentioned
    0 Post(s)
    Reputation
    0/4

    MVC, gebruik van ViewModels

    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?
    no votes  

  2. #2
    Curahee Q's Avatar
    Registered
    07/12/07
    Location
    Hoogstraten
    Posts
    854
    iTrader
    0
    Mentioned
    0 Post(s)
    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.
    no votes  

  3. #3
    SideShow's Avatar
    Registered
    21/08/02
    Location
    Roeselare
    Posts
    4,474
    iTrader
    15 (100%)
    Mentioned
    0 Post(s)
    Reputation
    1/35
    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.
    Last edited by SideShow; 29-06-2012 at 23:33.
    no votes  

  4. #4
    NeverwinterX's Avatar
    Registered
    27/08/04
    Location
    Leuven
    Posts
    930
    iTrader
    0
    Mentioned
    0 Post(s)
    Reputation
    11/38
    Quote Originally Posted by Curahee Q View Post
    This quote is hidden because you are ignoring this member. Show
    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.
    I am thee and thou art me and all of one is the other.
    TED talk: Richard Dawkins on militant atheism
    no votes  

  5. #5
    Cycloon's Avatar
    Registered
    18/01/04
    Location
    Melle
    Posts
    10,535
    iTrader
    56 (100%)
    Mentioned
    0 Post(s)
    Reputation
    27/102
    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.
    “In terms of how we evaluate schooling, everything is about working by yourself. If you work with someone else, it’s called cheating. Once you get out in the real world, everything you do involves working with other people.”
    PSN: Cycloon - Final Fantasy XIV: A realm reborn character
    no votes  

  6. #6
    Moto's Avatar
    Registered
    17/07/02
    Location
    Wilrijk
    Posts
    1,994
    iTrader
    2 (100%)
    Mentioned
    0 Post(s)
    Reputation
    9/16
    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?
    no votes  

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

Log in

Log in