Lets assume I load some business collections eagerly with NHibernate, EF or any ORM tool you wish…
Now I have an IList where each Customer has many Orders and each Order has many Products.
You have a GetAllCustomer() method in your CustomerRepository.
WHERE do you and HOW do you aggregate all your data into THREE ObservableCollections of type
Customer, Order and Product because I need add/delete notification events !?
Do you really do something like that in the BillingViewModel where you execute the customerRepo.GetAllCustomer():
BillingViewModel.cs
private ObservableCollection<Customer> _customersOC = new ObservableCollection<Customer>();
public BillingViewModel()
{
var customers = customerRepo.GetAllCustomer();
ConvertDomainToUICollections(customers);
}
private ConvertDomainToUICollections(IList<Customer> customers)
{
foreach(Customer c in customers)
{
_customersOC.Add(c);
foreach(Order o in c.Orders)
{
// Here I do not know how to proceed and put each in another OC<Order> etc...
}
}
}
Personally, I try to aggregate data like this only when required, and at the “lowest level” possible.
For example, in the BillingViewModel, I’d do an aggregation like this for Customers. However, I wouldn’t do Orders here – but rather, handle this within the CustomerViewModel, since I’d try to set it up so that I edit Orders on a specific Customer.
If you need to do this at the very high level, you’ll effectively be rewriting your entire Model. This can be done, but it really reduces the usefulness and maintainability of your data, since you’re effectively maintaining two full versions of the Model at a very high level.
That being said, many ORMs handle this much more nicely for you. For example, Lightspeed (one of my favorites) just makes their collections automatically implement
INotifyCollectionChangedstraight from the ORM. This makes it unnecessary to convert intoObservableCollection<T>– you can just use the data as returned from the ORM.