Click here to Skip to main content
14,695,532 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I’m struggling with this concept, as I haven’t been able to find a good example or ample discussion. I’m having a hard time understanding how to structure a WPF MVVM app that has multiple nested collections.

The application is to view Technical Support Tickets from an SQL2000 database. The collection of Tickets has separate collections of Events, Escalations, and RMAs. One Ticket can relate to zero or more Events, Escalations, or RMAs. To make it a bit more complicated, I’m not just displaying the collections with what I pull from the database, I’m also providing summary and total properties that I want to display in the DataGrid.

I have MainWindow View (Window), TicketsView (UserControl), and TicketView (UserControl). Those correspond to MainWindowViewModel, TicketsViewModel, and TicketViewModel respectively. Then there’s Ticket, Event, Escalation, and Rma Model classes; and a TicketRepository class that interacts with the database. Where should I locate the ObservableCollections, and what should those collections be? I can create an ObservableCollection<Ticket>; in TicketsViewModel that the TicketsView.TicketsDataGrid binds to; and just create the TicketViewModel when the SelectedItem passes the Ticket object. However that doesn’t allow me to have the calculation/total properties in the DataGrid.

Any assistance or guidance would be appreciated.

What I have tried:

I’ve tried already creating the ObservableCollections with just the Model object and creating the ViewModel object after SelectedItem passes the Model class. Works well, if I don’t have any summary/total properties; and if I follow the more popular opinion of keeping those properties out of your Model classes.

I then created ViewModels for anything that required those types of properties, instead of just creating them when passed the object. This gets really complicated fast and seems like it may not be right. I’m okay creating all the TicketViewModel items; as there is a corresponding TicketView UserControl. I don’t have Views corresponding to EventViewModel, EscalationViewModel, or RmaViewModel; as they’re only showing in the EventsDataGrid, EscalationsDataGrid, and RmasDataGrid inside TicketView. Or is that okay? Or, should I have some other sort of custom collection or wrapper for those collections that has the properties and Model object with the properties I’m exposing?
Updated 4-Jul-16 20:36pm
Potu Nani 23-Oct-19 10:44am
private ObservableCollection<holiday> _HolidayListCollection;
public ObservableCollection<holiday> HolidayListCollection
get { return _HolidayListCollection; }
_HolidayListCollection = value;
and i need that
HolidayListCollection = ClonedHolidayListCollection.Where(y=>y.HolidayDate.Value.Year.ToString()==SelectedYear) as ObservableCollection<holiday>;
but getting null value ?

1 solution

sure go ahead!
this is fine, and even what people do

class MyViewModel : ModelBase
  public AModel MyProperty
    get { return mProperty; }
    set {
      mProperty = value;
  public ObservableCollection<othermodel> Children { get; } = ObservableCollection<othermodel>

In fact you do whatever you want!
The only one thing to remember is that these "ViewModels" are models for the views. As such their (only) constraint is the following: *if a change must be reflected in the view, an INotifyPropertyChange or INotifyCollectionChanged (which ever appropriate) must be fired with it*.
It just happen that
class ObservableCollection<othermodel> : INotifyCollectionChanged</othermodel>
bnmc 5-Jul-16 12:55pm
Thanks for the reply Super Lloyd. It's amazing that this concept isn't discussed much and only seems glossed over. And, the argument from many developers on where to locate some things as it relates to MVVM, makes it more difficult to work this out. Thanks for confirming this is accepted.

I did finally find an article though I hadn't stumbled on before. It discusses just this, about what the responder found confusing. Specifically, "Another kind of object that fits in the ViewModel layer is a wrapper around a Model object that gives it behavior and makes it more usable by a View..." The author goes on to mention about "thick" vs. "thin" ViewModel layers. I strongly suggest reading his response, as it also has a very good explanation.

With your answer and the article I found, I'm going to mark your response as the answer. Thanks for confirming this is an acceptable way to do it!
Super Lloyd 5-Jul-16 17:38pm
You're welcome! :)
MVVM might seem confusing at first.. but it will become great once you understand it! :)
Don't other think it! ;)

Just think of it as MV (Model - View) the VM (ViewModel) is just a wrapper around the model to supplement it with change event and add property irrelevant to the Model, like public ICOmmand ClickCommand

And it make like really easy once you master it because:
1. there is (almost) enough support build-in XAML to make it happen relatively easy (you will have to add some helper code, such as the famous DelegateCommand)
2. separating UI and model "despaghettify" your code

Don't worry too much about big concept such as "separation of concern" the simplicity should become apparent quickly. if it's not after 1 or 2 project, give it up. It might help you understand! ;)

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900