views:

336

answers:

2

I have aggregated models like Customer:Order:Product.

As my View is bound to the BillingViewModel which has a Property Customers of type ObservableCollection

and ONE customer in this collection has a "list" of orders named ObservableCollection

and ONE order in this collection has a "list" of products named ObservableCollection

Well I need the ObservableCollection`s for databinding but should a domain model really have a ObservableCollection ? normally it has a

List or IEnumerable !

Is this bad habit or having side effects?

I append an explanation to the above what is right:

class Customer
{
   int CustomerID {get;set;}
   ObservableCollection<Order> { get;set;}
}

class BillingViewModel
{
  ObservableCollection<Customer> _customers;

public BillingViewModel()
{

  Customers= GetAggregatedCustomersOrdersProductsFromRepository();

}

public ObservableCollection<Customer> Customers
{
   get{ return _customers;}
   set
{
  _customers = value;
  this.RaisePropertyChanged("Customers");

}
}

}

I hope its more clear now! I have ObservableCollection in my ViewModel and Model!

A: 

It depends on if those properties need the built in change notification. If you have some kind of logic that depends on doing something when those change state, then it's fine. If it's only there to support data binding and that class is not itself a ViewModel, then I think it's bad form.

Tejs
there is no logic. I just add a order in the View and in my BillingViewModel the CurrentOrder is added to the SelectedCustomer likeSelectedCustomer.Orders.Add(CurrentOrder);then my DataGrid with Orders is immediately updated.Using a List<Order> there is no update in the View :/So what can I do about the bad form you say...?
msfanboy
If your BillingViewModel is using an ObservableCollection, then nothing is wrong. It's only if your objects that don't interact with the View have them that it is bad form.
Tejs
ah no you misunderstood me! I updated my first post above!
msfanboy
@Tejs: Why is it bad? :)WHERE is it written a domain collection must be a List<T> or IEnumerable<T> ??
msfanboy
A: 

From the examples I have read it appears that one practices is to take your Domain model Customer:Order:Product and rearrange it into MainViewModel:CustomerViewModel:OrderViewModel:ProductViewModel when it reaches the client side. This would allow you to mark any of the VMs dirty and save only when needed. It would also allow you to compose your View of many Views each driven by their own VM, so if later you decided to change the View from one large Screen into many Modals it would be fairly seamless. The reason for the MainViewModel, is more of a Controller then a ViewModel, its duty would be to get the Domain Model and break it apart into the VMs and also could be the Controller for how your Views will be displayed (Grouped or Modal), it could also contain Commands such as SaveAllDirty.

Agies
I do not need that "dirty" stuff. My data is saved when the user press a command after he enters data."... and rearrange it into MainViewModel:CustomerViewModel:OrderViewModel:ProductViewModel..."this I did before and its total overhead...
msfanboy