 |
|||||||||
|
|||||||||
|
|
Before I get into a description of the new feature, I'll walk you through the problem that it solves. In case you didn't know, CLINQ is a library that allows your LINQ queries to remain "alive" (or "Continuous") after their initial creation. This means that you can create a query like this:
myTransactions = from tx in allTransactions
where tx.DestinationCode == "05020"
orderby tx.ProcessDate descending
select tx;
and your result set will continue to automatically update itself as changes occur in the source collection (including changes that occur to items already in the source collection). This is the heart of the functionality that CLINQ provides. However, in v1.x there is a performance problem here that is actually rather large.
Let's say that, in the preceding query, the Transaction class has 30 properties. Further, let's assume that 10 or 15 of those properties are changing rapidly, perhaps hundreds of times per second. These properties change as the transaction flows through the system and is poked and prodded by various operating workflows and other monitoring processes. The problem here is that these 10 or 15 property changes really don't matter for our original query.. the DestinationCode property rarely changes, if at all.
Under CLINQ v1.x, even if we don't care about those other property changes, we could be looking at re-evaluating the query up to 1500 times PER SECOND because the query is re-evaluated for each property change it detects on a source object, and we've got hundreds of irrelevant property changes occurring on 10-15 different properties per second. Multiply that inefficiency out by the number of items in your source set, and you've got a huge problem. You might be thinking, "That doesn't bother me, my data doesn't change that rapidly". Well, your data could change that rapidly in the future. Also, if you're working with financial data, 1500 changes per second is a lowball estimate and you could be looking at far more than that.
This is where CLINQ v2.0 comes in. In CLINQ v2.0, every lambda you pass to the CLINQ extensions is now treated as an Expression. As a result, we can now troll through the entire expression tree, parse out the list of monitorable properties you used in the expression, and only listen for when those specific properties change.
As a result, you could have 1500 property changes per second, but CLINQ v2.0 will remain completely idle until one of those property changes modifies a property that could impact your result set. It will NOT respond to property changes that will have no impact on your result set. This is what we're calling Smart Property Notification. Using Smart Notification, we are seeing exponential performance increases in some circumstances.
Once we were able to do Smart notification using Expression trees, it was a logical next step to allow DEEP notification. This means that you can use nested property references in your CLINQ expressions and CLINQ will actually walk the DEEP property access tree, and only listen to changes on the bottom-most object, and only to the properties on that object that are meaningful.
This means that we can re-write the above query to handle a more robust underlying business object model:
myTransactions = from tx in allTransactions
where tx.Destination.DestinationCode == "05020"
orderby tx.ProcessRecord.ProcessDate descending
select tx;
Note how the preceding query is actually traversing a hierarchical object graph to get the job done. If the DestinationCode property on the Destination object (which is a property) changes, or if the ProcessDate property on the ProcessRecord property object changes, then CLINQ will perform a re-evaluation. Otherwise, CLINQ will remain completely idle.
None of this would be implemented without the awesome contributions of people like Andy Kutruff and without the open source concepts that are being fostered by sites like CodePlex.
You can grab the latest source code to CLINQ 2 (or preferably wait for the actual release) at CodePlex's CLINQ site .
This is the kind of stuff MS should have put in the .NET Framework. Nice
job!
