Their are 2 problems both these packages try to solve: Lack of a CollectionChanged event and Dynamic result sets. There is one additional problem bindable solves, additional automatic event triggers.
The First Problem both packages aim to solve is this:
Objects returned by a LINQ query do
not provide CollectionChanged events.
Continuous LINQ automatically does this to all queries, with no change:
from item in theSource select item ;
Bindable LINQ does this when you add .asBindable to your query Source Object:
from item in theSource.AsBindable() select item ;
The Second Problem both packages aim to solve is:
Result sets returned from a LINQ Query
are static.
Normally when you do a LINQ Query your result set is unchanged until you do a new query. With these two packages, your result set is updated whenever the source is updated. (bad for performance, good for realtime updates)
Example
var theSource = new ContinuousCollection<Customer>();
var theResultSet = from item in theSource where item.Age > 25 select item;
//theResultSet.Count would equal 0.
Because your using Bindable or Continuous LINQ, you could modify theSource, and theResultSet would automatically include the new item.
theSource.Add(new Customer("Bob", "Barker" , 35, Gender.Male)); //Age == 35
//theResultSet.Count would now equal 1.
The Additional Problem Bindable LINQ offers: (Quoting directly from their own page)
contactsListBox.ItemsSource = from c in customers
where c.Name.StartsWith(textBox1.Text)
select c;
Bindable LINQ will detect that the
query relies on the Text property of
the TextBox object, textBox1. Since
the TextBox is a WPF control, Bindable
LINQ knows to subscribe to the
TextChanged event on the control.
The end result is that as the user
types, the items in the query are
re-evaluated and the changes appear on
screen. No additional code is needed
to handle events.
