innoQ

Hartmut's BoxHartmut Wilms’s Weblog


« Mai 2005 | Main | November 2005 »

14.09.05

A hope for native XML support in C#: The LINQ Project

Yesterday I mused about an intuitive way of accessing XML messages and today I read about The LINQ Project:

The LINQ Project is a codename for a set of extensions to the .NET Framework that encompass language-integrated query, set, and transform operations. It extends C# and Visual Basic with native language syntax for queries and provides class libraries to take advantage of these capabilities.

It seems that Comega features have made their way into C# 3.0 sooner as I could have hoped. The C# LINQ features are demonstrated in an MSDN video. A technology preview can be downloaded here.

I’ve got to give the preview a try. Maybe all my hopes will be fulfilled in the “near” future. If Microsoft will some day succeed in shipping new releases, that is …

Posted by Hartmut Wilms at 13:45 | TrackBack

12.09.05

Is Microsoft doing the "hide-the-paradigm-from-those-dumb-developer-idiots" thing, again?

There is a “nice” discussion going on between Rich Turner and John CJ. Stefan already summarized and commented the highlights. If nothing else this post is intended to show that there is at least one reader of his blog, who is “.NET aware” ;-).

The thing which strikes Stefan and me most is, that John CJ stated in his last response: “At the heart of the internal model of Indigo is a very powerful concept of a message. Unfortunately, this conceptual model is never exposed to developers and architects directly.”. At first I was shocked and thought: No, this can’t be true. They couldn’t have done it, again. After calming down I read the comments by Stefan and John on John’s last blog entry, which fortunately made me relax, again.

The Process Message API, described by Don Box in this old post, still seems to be existing in WCF (Indigo).

I cannot understand John’s point. My best guess is, that he wants WCF to provide a message-oriented API as far as processes are concerned and an object-oriented API as far as data are concerned. This seems to be a little bit weird. Among many other benefits, which John and I agree upon, a major pro of message-oriented programming is, that message data are much more “loosely coupled” than objects. By serializing messages into objects, the message payload is bound to the classes generated from a single service description version. If the message payload changes, even by a minor, additional, optional element, every participant has to update its generated Classes, which represent the message payload. Is this “loosely coupled”? I doubt it.

What is missing, is a higher level XML API, which provides an easy and intuitive access to every message element and attribute.

Posted by Hartmut Wilms at 12:28 | TrackBack