I’ve recently started using Wintellect PowerCollections for my .NET 2.0 work. In case you don’t know it yet, that’s a very nice generic implementation of collection classes, similar in purpose to what the C++ standard template library has to offer. Peter Golde is the lead developer on this project and there’s the PowerCollections blog for those who want to follow development closely. In a recent blog post, Peter outlined where the project was going, with steps that will be done and also two steps that won’t be done. One of these not-to-be-done steps was about the priority queue functionality that had originally been planned in the PowerCollection specs. In the newer posting, Peter suggested that the
OrderedSet classes, which are already available, could be used for priority queue functionality, so a special class for the same purpose wouldn’t be needed.
In a recent MSDN TV interview, Mike Clark talked about (and demonstrated) the capabilities of the technology in the System.Transactions namespace, coming in .NET Framework 2.0. In other blog postings, such as in Angel Saenz-Badillos’ posting Whidbey ADO.NET System.Transactions Distributed Transactions and in Florin Lazar’s posting Transactions made easy: System.Transactions I found additional information on the topic. But all those publications have one thing in common: they look at the technology purely from the users’ point of view, not from the point of view of a participant in such a transaction.
Now, especially considering the availability of the new lightweight transaction manager (LTM), I was interested to find out what I’d have to do to be able to take part in a (potentially distributed) transaction with my own objects, as coordinated by
System.Transactions. Before I go on describing my findings (and the things I haven’t yet quite understood), let me mention that I have no experience whatsoever with
System.EnterpriseServices, so some misunderstandings may certainly be due to my ignorance.
In newsgroup post in the Developer Express support newsgroup for their XPO product, I was recently asked if it was possible to show information that’s really stored in a one-to-many relationship as additional columns on the main object. Actually, .NET makes this possible using an implementation of the
ITypedList interface together with a custom property descriptor – in this way, arbitrary additional properties on an object can be “simulated”, regardless of the real source of the data. First, let me explain the problem in the sample case (a download link is at the bottom of the post) a little further. Let’s assume you have a class (
MasterRecord) that stores a collection of detail values (
DetailValue) objects in a typed collection. The following diagram shows the structure, just as an overview of the classes involved: