0

I'm building a WPF application and while creating my domain model I used ObservableCollection<T>.
I allowed myself to use it only because it clearly belongs to the System.Collections.ObjectModel namespace.

During execution I received an error. I found a thread in SO already deals with the problem in here: Where do I get a thread-safe CollectionView?

My question is: assuming ObservableCollection<T> is in System.Collections.ObjectModel namespace, why does it have a user interface related limitation? Is it an architecture flaw or intended? Is it good practice to use it in domain model?

Community
  • 1
  • 1
G.Y
  • 6,042
  • 2
  • 37
  • 54

1 Answers1

2

I don't view this as a design flaw at all. And we use them in our WPF domain models. We just make sure that anytime we update our observable collections, we do so on the UI thread. This is very easy to do. We've also created our own implementation so that anytime we update our observable collections, we disable the collection updated method until all items have been added or removed. This greatly increases binding performance.

Randy Minder
  • 47,200
  • 49
  • 204
  • 358
  • but what happens if I want to update the collection from a non-ui process? what happens if I had no UI in my app - would I be getting the same error when trying to update? - if so it is clearly not belong to the objectModel namespace. – G.Y May 06 '12 at 12:26
  • 1
    If you have no UI, or a non-UI process, why are you using an ObservableCollection? These are primarily used for binding to WPF UI objects. – Randy Minder May 06 '12 at 12:39
  • because I want the functionality of notify when somthing is changed in the collection... it is very helpful in the domain model. but if it was not designed to be independent / in the BL layer - I would not use it. – G.Y May 06 '12 at 14:04
  • You can easily do this without using an ObservableCollection. – Randy Minder May 06 '12 at 17:27