.net 4.0 collections

.net 4.0 Collections Overview

• System.Collections
• System.Collections.Concurrent
• System.Collections.Generic
• System.Collections.ObjectModel
• System.Collections.Specialized

VVVV.Core.Collections

This namespace contains vvvvs own set of collections which where mainly created to overcome two limitations of the available .net collections:

• get notifications when a collection changes so we can provide automatic collection syncing (see below). (could now also be realized using ObservableCollection)
• have truly readonly collections (we don't use ReadOnlyCollectionBase because it's not generic)(but ReadOnlyCollection<T> is!?)

Therefore VVVV.Core.Collections contains:

• EditableCollection<T>
• EditableList<T>
• SortedEditableList<T>
• EditableIDList<T>
• ViewableCollection<T>
• ViewableList<T>
• SortedViewableList<T>
• ViewableIDList<T>

where the term Viewable means that you cannot add or remove items to and from those collections. Se we have:

• Collections
• Lists (ordered collections, can be sorted manually)
• SortedLists (always sorted lists)
• IDLists (entries are IIDItems, think of an IDList as a namespace in which all elements have different names)

The main purposes of our set of collections is to

• ease object graph modeling
• support both viewable-only & editable collections
• ease external syncronization with & modification of that model.

Create an EditableCollection

public class MyModel
    {
        public IEditableCollection<int> Numbers
        {
            get;
            private set;
        }
 
        Numbers = new EditableCollection<int>();
    }

A model that wants to expose a collection typically uses a property that can only be accessed, not written (get; private set) and the collection is created in the constructor. Typically it is sufficient to expose the interface to the collection.
The central idea now is that your model can be changed through its exposed collection property. So you would NOT need to introduce some custom AddNumber() / RemoveNumber() methods to your model. Users just directly work with the editable collection. That's the way to go.
In other words the collection should be perceived as a first class citizen within your model. That way the use of such a model is straight forward. When you want to change a collection of a model, you do just that. As a result, adding and removing objects from collections can also be done with standardized commands, which is a plus.
Now, if you need to react to a changing collection within your model, you can subscribe to the events of the collection (sometimes even that can be omitted like seen in the syncer example on the bottom of the page).

Our collections make it easy to decide which collections might be edited or only viewed from outside. All flavours of collections come as either editable or viewable (can't be edited). Here is how to use a viewable collection:

Create a ViewableCollection

public IViewableCollection<int> Results
        {
            get;
            private set;
        }
 
        FResults = new EditableCollection<int>();
        Results = FResults.AsViewableCollection();

Above you see how to build up a list, that can be edited within the model object, but only be viewed from outside.

Syncing

One Collection can stay in sync with another collection, even if it manages another type of elements. A syncer will react on each event of the first collection and change the second collection accordingly.

You only need to specify a mapping that creates an element in the second list based on an element of the first.

public IEditableList<int> Numbers
        {
            get;
            private set;
        }
 
        private EditableList<int> FResults;
        public IViewableList<int> Results
        {
            get;
            private set;
        }
 
        public void TestMethod1()
        {
            Numbers = new EditableList<int>();
 
            FResults = new EditableList<int>();
            using (FResults.SyncWith(Numbers, x => x * x))
            {
                Results = FResults.AsViewableList();
 
                // when doing more than one change: 
                // use beginupdate/endupdate to reduce syncing events
                Numbers.BeginUpdate();
                try
                {
                    Numbers.Add(4);
                    Numbers.Add(7);
                }
                finally
                {
                    Numbers.EndUpdate();
                }
 
                // Magically results (x*x) are already added to the Results list
                foreach (var r in Results)
                    Debug.WriteLine(r);
 
                // You can't add a result to the public Results list
                // Results.Add(17);
 
                // again: change source collection:
                Numbers.Add(8);
 
                // synced results collection is already updated.
                foreach (var r in Results)
                    Debug.WriteLine(r);
            }
        }

Above you can see how a syncer can be used to model a collection depending on another collection.

Note that the standard case to use syncing however is to sync a collection of views onto you model objects.

For that just create a private editable collection and sync it with the model collection by passing a delegate that creates a view object for your model object. If you still need to do more than just creating and disposing your view think of reacting on syncer events or events of your own synced list...