1

I'm comparatively fresh to C# and WPF, so forgive me for any lack of clarity in this question.

I developed my datamodel as a class library, such that it's not tied to a particular UI framework, or indeed any UI at all. There is good reason for this, as the library may be used to support multiple UI implementations.

Let's suppose it looks like this:

public class MyDataStore
{
        public string Title { get; private set; }

        public List<MyDataRecord> Records { get; private set; }
}

I then have a UI for viewing and manipulating this datamodel; let's suppose it's a WPF form with a DataGrid.

Now you can't bind to a List, which is fine. Were this entirely a UI project, I could simply change Records to be an ObservableCollection, but this doesn't suit this library - aside from the principles of it, I update the list from a worker thread, and you can't push that operation onto a UI thread if you don't know about a UI.

The direct manual replacement is maintaining event subscription for every list item and cascading it up through the hierarchy - ick. Alternatively the UI has to adopt subscription on a per-item basis, which is a departure from the current state of it handling everything on a top-down basis.

I can think of a few designs that would work around this, but it must be a common problem: is there an appropriate design, pattern or framework to get the benefits and ease of binding, whilst maintaining distinct UI and model separation?

Rob Pridham
  • 4,780
  • 1
  • 26
  • 38
  • 1
    `and you can't push that operation onto a UI thread if you don't know about a UI.` - I have resolved that by abstracting the `Dispatcher` away. You could also do `TaskFactory.FromCurrentSynchronizationContext();` – Federico Berasategui Apr 03 '14 at 16:03
  • 1
    Anways, [`System.Collections.ObjectModel.ObservableCollection`](http://msdn.microsoft.com/en-us/library/ms668604(v=vs.110).aspx) is defined in System.dll. I don't think that is tied to any UI framework at all. – Federico Berasategui Apr 03 '14 at 16:06
  • 1
    This example sounds like the same issue you are running into: [Link](http://blog.lexique-du-net.com/index.php?post/2010/02/24/MVVM-Creating-ViewModel-%3A-wrap-your-business-object-%28solution-1-of-n%29.). He proposes two solutions, the more intriguing one by creating a proxy: [His Solution](http://blog.lexique-du-net.com/index.php?post/2010/03/02/M-V-VM-How-to-keep-collections-of-ViewModel-and-Model-in-sync) – jsirr13 Apr 03 '14 at 16:10
  • I like the idea of abstracting the Dispatcher - that could work well here, and bears further investigation. As for ObservableCollection, you're right; I conflated the requirement of running in the same thread with requiring interaction to be on the UI. – Rob Pridham Apr 03 '14 at 16:11
  • 1
    For me personally, I just keep ObservableCollection's and Property Notification's on my model's properties. I've seen arguments made both ways, but to me it keeps things easy. And I found a thread safe implementation of [ObservableCollection](http://stackoverflow.com/questions/7687000/fast-performing-and-thread-safe-observable-collection). – jsirr13 Apr 03 '14 at 16:12
  • 1
    @jsirr13 - thank you for your comments, and the link in particular, which I've used to achieve what I wanted. – Rob Pridham Apr 04 '14 at 07:56

1 Answers1

2

Either create proxy classes that implement INotifyPropertyChanged, along with ObservableCollections (AutoMapper helps with switching between them)

Or add those features directly to your Model objects.

I usually add this to the model, as notification upon a property changed is not UI specific (yes UI does use it, but you may need to use it somewhere else in future, e.g. if you need one of your classes to listen if a child class changed its value)

Michal Ciechan
  • 13,492
  • 11
  • 76
  • 118