c# - Usage of BindableBase in classic MVVM design -

i little bit confused usage of bindablebase class , how apply "new" mechanism classic mvvm design.

briefly, question following: how use correctly bindablebase class when have reference model in our view-model class?

details:

classical mvvm pattern: view <-> view-model -> model

as see view-model in scheme knows model, model knows nothing view , view-model.

if implement approach, have this:

// model class task {...}  // view-model class taskviewmodel : bindablebase {     private readonly task _task;      public taskviewmodel(task task)     {         _task = task;     }     ... } 

let's imaging task class has 'subject' property , should show data. according mvvm should:

create duplication of 'subject' property in view-model:

// view-model class taskviewmodel : bindablebase {     public string subject     {         get{ return _task.subject; }         set         {             _task.subject = value;             // can't use setproperty(ref _task.subject, value)            // it's contradict c# syntax            onpropertychanged("subject");         }     } } 

as see can't use setproperty method such design , way it's calling of raw onpropertychanged method.

it seems setproperty biggest benefit of bindablebase class , it's strange can't use in such direct , common implementation of mvvm. thought maybe missed or work incorrectly specified class.

do know how use bindablebase specified design , code improvement?

thanks

currently, viewmodel exposing model properties view. fine becomes quite ridiculous if model has lots of properties need exposed. can imagine having create properties model has 20+ properties?

instead, should expose model view using property inside viewmodel.

public myclass model { get; private set; } 

note: can implement inotifypropertychanged.

and properties in model should implement inotifypropertychanged, or in case, bindablebase.

public class myclass : bindablebase 

your view can bind directly model property. may seem you're breaking design pattern not case, view still knows nothing model, makes assumptions properties it's expecting, therefore classes still decoupled.

the downside here model depends on bindablebase, isn't end of world if in situation can't modify model classes, current approach way go.