c# - Proper MVVM ViewModel and Model pattern -

i haven't found exact answer this. people have mentioned binding directly model inappropriate mvvm, i'm trying decide if following pattern still follows mvvm:

view:

<textbox text="{binding infoforprocessing.batchid}"/> <textbox text="{binding infoforprocessing.batchstatus}"/>

viewmodel:

private processingtaskmodel _infoforprocessing; public processingtaskmodel infoforprocessing {         {         return _infoforprocessing;     }     private set     {         _infoforprocessing = value;         raisepropertychanged();     } } .... //doing processing...then tell model populate data: infoforprocessing.resolvebatchinfo(...); 

model: (implements inotifypropertychanged)

private string _batchid; public string batchid   //viewable {         {         return _batchid;     }     private set     {         _batchid = value;         raisepropertychanged();     } }  private string _batchstatus; public string batchstatus  //viewable {         {         return _batchstatus;     }     private set     {         _batchstatus = value;         raisepropertychanged();     } }  public bool resolvebatchinfo(...){     //get data database...     ...     //now populate properties retrieved data (or return false on error)     batchid = dr[0].tostring();     batchstatus = dr[1].tostring();     return true; } 

i see way this. can copy properties viewmodel, bind them, , have viewmodel populate them when returned model.

for current project here, of data in model dependency of queries performed later

i've made sure encapsulate as possible, , expose properties view , viewmodel needs see, while restricting setters well.

your design, is, non-conforming in opinion, data object contains model logic (the resolvebatchinfo method). here 2 potential solutions:

1. have seperate view model , model objects. in scenario, each has own methods. inpc view model classes , database methods in model classes. (as shown here)

2. have pocos "float" between layers. important part here besides inpc, there no logic in objects, data. under design, have separate model class encapsulates data operations , have method returned populated batchinfo objects.

i (2) in own projects, provides better seperation of concerns , limits code/data replication.

of course, of 3 approaches (my 2 plus yours) important factor writing code makes sense not "pure" mvvm. go design make life easiest down road.