Tim Jeanes: Microsoft TechEd (Wednesday)

We saw some more of LINQ this morning, and holy crap! - this is so going to change the way we work! It just makes it so easy to get your hands on exactly the data you need where and when you need it. When combined with the new anonymous classes in C# in .NET framework 3.0, you get all the type casting and intellisense you'd expect from a proper class, but without the hassle of creating a whole new class just for that one time you want to use it. So, on your customer list page you can create an anonymous class on the fly that holds just the details you want from the customer table (with any aggregate data from child tables), without having to make a "CustomerSummaryDetails" class to hold it. It's a beautiful thing.

I was very impressed with how LINQ saves data back to the database - it supports all common models for data concurrency and transactions right out of the box. However, it frightened me a little that if you query the same table twice, both resultant datasets will refer to the same object in memory. This has the potential to be either very powerful or very dangerous. Similarly, I'm not convinced we'll still have enough control over how LINQ saves changes to child tables. We caught the speaker at the Ask The Experts stand over lunch and though he put our minds at rest over some issues, we managed to throw him slightly with these kinds of questions, so I remained unconvinced.

I later attended an extended Q&A session with Anders Hejlsberg - the head of C# language design - who also had a big hand in LINQ. I think it'll take a bit of a paradigm shift on our part: whereas Gentle.NET takes snapshots of the data in the database and lets you play with them in object form, LINQ considers your objects to be a representation of the underlying data: you only have one instance of that object in memory, just as there is only one instance of the object in the database. Everything we already do is still possible (and slicker in many cases), but we'll just have to alter the way we handle our objects a little.

Hejlsberg talked about his future plans for C#. Microsoft will be taking their current support for partial classes one step further by enabling partial methods too: you can define the signature of a method in one half of your partial class and then instantiate it (if needed) in the other. (If you don't instantiate it then the compiler removes not only the method signature, but also all calls to that method.) This perfectly fits a problem we've hit regarding the validation of classes, one half of which has been created by a code generator.

We'd found a work-around, but as Hejlsberg said that this exact use is the main driver for introducing this new feature, it's nice to see that we're one step ahead of the game! Incidentally, Hejlsberg also said that partial classes were introduced in the first place to enable the safe regeneration of code after the underlying database changed. This is exactly the use we've made of them - it fixed the inheritance workaround we'd used before - another encouragement that our coding practises are right up there with the best of them! omg omg 1337 hax!

Another interesting session today was looking at the ASP.NET AJAX toolkit. Microsoft are providing a good-sized library of out-of-the-box AJAX controls, and though we've not had the business incentive to use them in the past, I think the ease of use I saw today means that we'll be incorporating these into our web applications in the very near future. They're supplying pretty well every type of control that will be commonly useful, and they're all vastly configurable. The demonstration also covered how to build your own AJAX control using the various helper libraries that Microsoft have prepared (that handle everything from the browser-to-server interface to ensuring your control will work under the varying DOM models implemented by all the major browsers). Quite frankly, building your own control looks pretty horrendous, and it's the sort of thing you'll quickly forget unless you do it every day. However, as with most technologies it's enough to know that it can be done, and the ample resources on the web will fill in the gaps as and when you need them.

The session entitled 'Encrypting Without Secrets' took a look at the strengths and weaknesses of public/private key-pair encryption, highlighting the issue that all this generally achieves is transferring what the secret is from one thing to another. Initially your secret is that one big critical document, or perhaps your credit card details; after encryption you tend not to worry too much about who gets to see that encrypted text, so the secret now becomes your private key. Unfortunately, a private key is a lot smaller than a whole bunch of company secrets, and getting your hands on the key unlocks a whole load of valuable information. Typically the private key is kept on the server as the encrypted information, merely for convenience's sake. Avoiding this much-overlooked weak link in the chain is a fascinating topic, especially if you're not to introduce any other new weaknesses, whilst keeping your secure systems usable.

I really hope they do something different for lunch tomorrow though - they've served the same thing two days running now, and though I'm generally not averse to paella, I am when it tastes like that...