LINQ operators and extensibility
Sun, Jan 7 2007 11:41
I was just reading Rocky's blog entry and thought I'd clarify something Rocky said
Running a LINQ query across a BLB results in an IEnumerable<T>, where T is your BB-derived child type. At this point you’ve lost all n-level undo support, and data binding (Windows Forms, and any WPF grid) won’t work right either.
That's the "default" behaviour, but LINQ, unlike the mistakes of the past is really about extensibility. You can use the out of the box experience or you can easily roll your own. Let's take an example of a List( of Customer) with a Select query, such as :
Dim view = From c in Customers where c.State ="WA" Select c
Now sure this could just return an IEnumarable(Of Customer) but it can and usually does return more than that. with DLinq it returns collection types specifically designed to allow for entity tracking. For your own collection classes it too can use that information to do tracking and return your own custom collection class. The trick is to provide an extension method that is a better match.
In this example, I defined a method such as :
Public Function Select(Of t1 As Customer, t2 As Customer)(items As List(Of t1), comparer as System.Linq.Func(Of t1,t2)) as IEnumerable(Of t1)
and returned a new List(Of Customer). You could have this return a view using your business base collection or any other collection you like, plus you get to work with the original collection, enabling you to implement your entity tracking , n-level undo support, data binding interfaces or anything else important to your model.
To put it simply, LINQ is flexible and extensible. It provides more natural ways of interrogating data while also providing more intuitive ways of working with objects.