locked
MVVM Question, is that a good design or bad design...? RRS feed

  • Question

  • I have a solution with database project and a WPF UI Project. The database project should not be confused with VS DB Edition, it is a C# Class Library that has Model and Service routines for SELECT, INSERT, UPDATE, DELETE in my database. 

    Here is what I am doing, I will use the simple EMP-DEPT example to describe my design. The Department Employee relationship is one to many. So I have in my DB Project an Employee class and a Department class with List<Employee> as member

     

    In my UI project I have EmployeeViewModel and DepartmentViewModel with List<EmployeeViewModel> as member. Now each EmployeeViewModel is aggregating one object of Employee from DB Project and each DepartmentViewModel is holding one Department object inside.

     

    My question is, is that a good design ? Why this is good and if it is bad why it is bad ?

     

    Below is the class diagram

      Uploaded with ImageShack.us

     


    Fahad
    Thursday, June 23, 2011 2:01 PM

Answers

  • Hi,

     

    I don't think you should have a list of employeeviewmodels. you should still have a department view model which contains a list of employee models. 

     

    when a user selects an employee from your tree control you should notify your employee view model (via a mediator of some sorts) that it needs to go to the db and get the correct employee and re populate its properties with the data returned.'

     

    Does that clarify things? If I'm not understanding your situation correctly let me know.

     

    Thanks.

    • Marked as answer by Fahad349 Thursday, June 23, 2011 7:27 PM
    Thursday, June 23, 2011 4:31 PM
  • You shouldn't re-use the same viewmodel object instance in separate views.

    Assuming you mean form by view.

    The usual approach to handling data shared across multiple views is to use a repository and messaging or whatever to notify when the repository changes.

     

    It depends on how many employees you have whether it's worth virtualizing your treeview and loading employees on demand.

    You could, for example, use lazy loading with EF4.

    • Marked as answer by Fahad349 Thursday, June 23, 2011 7:28 PM
    Thursday, June 23, 2011 4:43 PM
  • mediator as in mediator pattern. ( standard pattern - google it ).

    Like a lot of these sort of pattern names Repository is a fancy name for something which can be fairly simple.  It's a central holder for your (model) data.

    There are various ways of telling viewmodels when data in  your repository has changed.

    You can, eg, subscribe to an event raised.

    Listen for messages ( take a look at mvvm lite ).

    Here are some links to chew on.

    http://horsdal.blogspot.com/2009/06/exploring-wpf-business-application_24.html

    http://stackoverflow.com/questions/3263748/wpf-mvvm-repository-pattern-query

    Or maybe you want to persist your data for occasional connection.

    http://petermorlion.blogspot.com/2011/05/repository-with-sterling-for-desktop.html

     

     

    • Marked as answer by Fahad349 Thursday, June 23, 2011 7:28 PM
    Thursday, June 23, 2011 7:02 PM

All replies

  • Hi Fahad,

     

    you are not far off but you are confusing a few of the concepts in MVVM. your employee and department are Models so they will contain properties such as ID, Name etc.

     

    Your view models are basically your datacontext for the UI of your view and should expose public proeprties, commands etc that your view can make use of. 

     

    so it should be -

    <b>db => Model => ViewModel => view ;/b>

    To answer your question about good or bad. My viewmodels have models that contain list of other models e.g department hasving a list of employeees.

     

    I don't view that as bad design and I wouldn't know how to code that any differently. 

     

    I hope that answers your question?

    • Proposed as answer by Pritesh3 Thursday, June 23, 2011 3:41 PM
    Thursday, June 23, 2011 3:41 PM
  • A viewmodel is a sort of an adapter and processor that connects your data to your view ( form ).

    You seem to be thinking of them as a sort of orm or something.

    The primary difference is that your viewmodel should suit whatever your form is going to be doing.

    So if you have a parent - child sort of screen where you select a department and want to see the employees then you might indeed have a department VM containing lists of employee vm.

    If you had a screen maintains departments then I'd expect to see a single departmentvm with no employees contained at all.

    Similarly if you have a screen adds an employee you might not have department at all if you had another screen then allocates some people to a department.

    Just to underline the obvious.

    You can have several viewmodels for any given table in an application if that suits the way your forms work.

    Thursday, June 23, 2011 3:56 PM
  • Thank you guys for replying

     

    Here are answers to your questions

    My view model is aggregating the dbModel object and exposing properties which returns data from internal dbModel objects for example

    inside EmployeeViewMode

    public string Name
    {
      get { return _modelEmployee.EmployeeName; }
     set { _modelEmployee.EmployeeName = value; OnPropertyChanged("Name"); }
    }
    


    Here is my current UI at a glance

    I have a explorer style application which shows a tree view having Departments, when department nodes are expanded, it lists all the employees within. For that purpose I have List<EmployeeViewModel> in DepartmentViewModel

    I have another view that lets user add employee to  a particular department. I am using same view model, actually same object of Department and Employee view models as in the tree view as in EDIT/ADD views. This comes in handy specially when one view modifies that data and tree view automatically reflects the changes.

    Does that make sense ?


    Fahad
    Thursday, June 23, 2011 4:15 PM
  • Hi,

     

    I don't think you should have a list of employeeviewmodels. you should still have a department view model which contains a list of employee models. 

     

    when a user selects an employee from your tree control you should notify your employee view model (via a mediator of some sorts) that it needs to go to the db and get the correct employee and re populate its properties with the data returned.'

     

    Does that clarify things? If I'm not understanding your situation correctly let me know.

     

    Thanks.

    • Marked as answer by Fahad349 Thursday, June 23, 2011 7:27 PM
    Thursday, June 23, 2011 4:31 PM
  • You shouldn't re-use the same viewmodel object instance in separate views.

    Assuming you mean form by view.

    The usual approach to handling data shared across multiple views is to use a repository and messaging or whatever to notify when the repository changes.

     

    It depends on how many employees you have whether it's worth virtualizing your treeview and loading employees on demand.

    You could, for example, use lazy loading with EF4.

    • Marked as answer by Fahad349 Thursday, June 23, 2011 7:28 PM
    Thursday, June 23, 2011 4:43 PM
  • Andy,

    Awesome. Please tell me more about using repositories to keep a shared Model object for all View Model objects of different types.

     

    Does that allow us to have singleton of identical model objects ? Example, only one object of Employee across the whole application address space of employee "John Doe" of Dept Sales and same object being used by all view models ?


    Fahad
    Thursday, June 23, 2011 6:27 PM
  • Hi,

     

    I don't think you should have a list of employeeviewmodels. you should still have a department view model which contains a list of employee models. 

     

    when a user selects an employee from your tree control you should notify your employee view model (via a mediator of some sorts) that it needs to go to the db and get the correct employee and re populate its properties with the data returned.'

     

    Does that clarify things? If I'm not understanding your situation correctly let me know.

     

    Thanks.

    Just found that your reply makes a lot of sense as well as O'Neil. I am now trying to find out that "Repository" mechanism he talked about, I would love to use that if it really exists.

    What that mediator would be ?


    Fahad
    Thursday, June 23, 2011 6:30 PM
  • mediator as in mediator pattern. ( standard pattern - google it ).

    Like a lot of these sort of pattern names Repository is a fancy name for something which can be fairly simple.  It's a central holder for your (model) data.

    There are various ways of telling viewmodels when data in  your repository has changed.

    You can, eg, subscribe to an event raised.

    Listen for messages ( take a look at mvvm lite ).

    Here are some links to chew on.

    http://horsdal.blogspot.com/2009/06/exploring-wpf-business-application_24.html

    http://stackoverflow.com/questions/3263748/wpf-mvvm-repository-pattern-query

    Or maybe you want to persist your data for occasional connection.

    http://petermorlion.blogspot.com/2011/05/repository-with-sterling-for-desktop.html

     

     

    • Marked as answer by Fahad349 Thursday, June 23, 2011 7:28 PM
    Thursday, June 23, 2011 7:02 PM
  • Came here by accident and saw a link to my old blog (the last link of Andy ONeill's answer). The new link is:

    http://www.petermorlion.com/a_repository_with_sterling_for_a_desktop_wpf_application/


    Friday, August 19, 2016 10:33 AM