MVVM - How to wrap ViewModel in a ViewModel?

Topics: Prism v4 - WPF 4
Aug 2, 2012 at 8:27 AM
Edited Aug 2, 2012 at 8:34 AM

First of all, I have read this post and did not find the answer for my problem.

I am not sure if this is an aggregated Model class or an aggregated ViewModel class, but this is what I have:

In my WPF (with Prism) application, I have a view 'Filter Customers View' that connects to a service and requests a list of 'Customer' objects, based on a filter.

The list that is returned from the service is this :

List<CustomerDTO>    FilteredCustomers;


And the CustomerDTO looks like this:

public class CustomerDTO
	public	Guid			CustomerId;
	public	String			Name;
	public	String			Address;
	public	String			PhoneNumber;
	public	OrderInfoDTO		LastOrderInformation;
	public	List<OtherClass>	ListOfSomething;


And the OrderInfoClass looks like this:

public class OrderInfoDTO
	public	Guid		OrderId;
	public	DateTime	OrderDate;
	public	int		NumberOfProducts;
	public	double		TotalAmountSpent;


And the OtherClass looks like this:

public class OtherClass
	public	Guid		Id;
	public	String		SomeText;


As you can see - the customer might or might not have a 'Last Order',

I would like to wrap the 'CustomerDTO' object in a ViewModel, so that I can bind it to the view.

This is what I thought of doing :

public class CustomerViewModel : NotificationObject
	private	CustomerDTO	_customerDTO;

	public CustomerViewModel(CustomerDTO customerDTO)
		_customerDTO = customerDTO;

	public Guid CustomerId
		get  {  return _customerDTO.CustomerId;  }
		set  {  _customerDTO.CustomerId = value; RaisePropertyChanged("CustomerId "); }

	public String Name
		get  {  return _customerDTO.Name;  }
		set  {  _customerDTO.Name = value; RaisePropertyChanged("Name"); }

	public String Address
		get  {  return _customerDTO.Address;  }
		set  {  _customerDTO.Address = value; RaisePropertyChanged("Address"); }

	public String PhoneNumber
		get  {  return _customerDTO.PhoneNumber;  }
		set  {  _customerDTO.PhoneNumber= value; RaisePropertyChanged("PhoneNumber"); }



  1. First of all - is 'CustomerDTO' what is known as a Model ? And is 'OrderInfoDTO' also a Model ? and what about 'OtherClass' ?
  2. How do I treat the 'OrderInfoDTO' in my CustomerViewModel class ? Do I create a 'ViewModel' for it also ? where do I create the 'OrderInfoDTO' view-model ??? What happens if now someone updates the customer and sets the 'OrderInfoDTO' value ?
  3. How do I treat the list of 'OtherClass' in my CustomerViewModel class ? Do I create an ObservableCollection for it ? What happens if someone will want to delete an item in it or update an item in it or add an item to it ?
Aug 2, 2012 at 8:26 PM


I believe that most of those questions do not have a "correct" or "wrong" answer, as they seem to be more related to designing decisions in your application. Hence, which approach you should follow will depend mostly on your personal preferences and the requirements of your scenario.

However, I will try to answer them providing my personal opinion:

  • Based on my understanding, a model could be as simple as a representation of data used in your application or as complex as a part of the data access layer in charge of the accessing the corresponding data. Therefore, I believe that all of the three classes can be considered Models (or at least, primitive types of models.) Also, in my opinion, you should wrap the attributes of your models inside properties, as attributes should not be accessed directly from outside of an object.

  • As far as I know, there is no limitation about using only one model per view model. Therefore, I believe your CustomerViewModel could also expose the OrderInfoDTO model or encapsulate it by exposing its data through other properties. Also, creating a separate OrderInfoViewModel for it is a valid approach. What is more, you could even divide the CustomerView in different and more modular views, creating a OrderInfoView for the OrderInfoViewModel. The same goes for the OtherClass model: for each OtherClass model in the collection, you could have an associated view and view model. As you can see, this is a designing decision. You can implement either a single view / view model or three separated ones.

  • In my opinion, if you only want to show the OtherClass collection of the CustomerDTO, the simpler approach is to simply expose them through a collection in the CustomerViewModel and consume the collection in the view. As you are not performing any presentation of business logic on the data contained in the OtherClass models, just showing it, it might no be required to have another view model for it, besides the CustomerViewModel. However, if you wish to edit OtherClass models, then it would be required to have a view model to handle these operations. The same goes for the OrderInfoDTO models.

  • In case you decide to use separated views / view models for each model, the challenge you will need to address is how the view models interact and shared data. This again, depends of your personal preferences and the requirements of your scenario. You could have the CustomerViewModel in charge of creating the other view models or you could communicate them in a more loosely coupled fashion using one of the communication approaches provided in Prism.

Again, in my opinion, this is more related to designing decisions rather that "correct" or "incorrect" approaches.

I hope you find this useful,

Damian Cherubini