I have this long-standing theory and thought I’d share it. The theory goes like this:

First there was DOS.

Then there was Windows which ran on DOS.

Then DOS was emulated in Windows.

Then there was .NET which ran on Windows.

Then Windows was emulated in .NET.

Of course that last bit hasn't happened yet, but I expect it is just a matter of time before Microsoft's OS becomes .NET and Win32 becomes an emulated artifact. I also expect that branding-wise Windows will remain the foremost brand. I think this is why the .NET brand is already being deprecated. .NET as a brand must fade so it can be reborn like the phoenix in the future - as Windows.

Here's a very astute article that highlights the reason Linux is virtually doomed to the same fate as Unix.

Years ago, before Microsoft was a serious company and I was still working on VAXen it was clear that Unix was in trouble. We all called it "Unixification" - the reality that each Unix vendor had to differentiate and to differentiate they had to vary from the "standard" and as they varied from the standard they created tiny little niche products that couldn't compete with each other, much less things like the VAX or AS400.

This is the core flaw with any standards-based product concept. If a product is standards-based then all products are the same, so the only way to compete is on price, service and maybe quality (though if the standard is any good then quality should be automatic). Any business person will tell you that this is a commodity market and very few people want to play in the commodity space because it is hard work for low margin.

How do you break out of a commodity market? By de-commoditizing your product. By making it unique and compelling. Hence Unixification. The making of Unix variants that are unique and compelling.

It should come as no surprise to anyone that the efforts to make money of Linux would give rise to the Unixification of Linux. Dare we say "Linuxification". Linux vendors don't want to be stuck in a commodity market any more than their Unix predecessors. The only way out is to de-commoditize Linux - to provide non-standard value-add in substantial ways.

Judge Jackson hit the nail on the head years ago in the Microsoft monopoly trial. He pointed out quite clearly that there is a natural monopoly in the operating system space. In short, there will be a monopoly in the OS - the only question is whether it is Windows, the Mac or a Linux variant.

This past weekend I spoke at two events in Milwaukee, WI.

On Saturday morning I spoke at Deeper in .NET, a local event organized by the Wisconsin .NET user group. They lined up sponsors, got a venue and had around 400 people show up for the free all-day event. The speaker line-up was pretty compelling, including Scott Guthrie and Rob Howard. I was impressed by the organization of the event and I think it was a great day!

In particular I’m very happy to see events like this and the Heartland Developers Conference (in Iowa) be so successful. Typically the big Microsoft conferences are on the coasts – San Francisco, Orlando and so forth. While those are nice destinations, the fact is that we here in the middle of the country want the same content, the same speakers. Events like this one on Saturday bring the speakers and content to the audience, and that is an awesome thing!

Personally though, I think those of us in Iowa, Wisconsin and Minnesota should organize the events in May, June or September. Organizing these events when the weather is cold just reinforces people’s misguided perception about this part of the US. During the months of May, June and September the weather (at least in Minnesota) is as nice as you’ll find anywhere. Probably nicer. And Minnesota is beautiful in those months, all green trees and blue water.

On Friday and Sunday I spoke at the No Fluff, Just Stuff Software Symposium (NFJS). This conference is different from any other I’ve done, and I think is somewhat unique in general.

What makes NFJS unique in general is that they cap attendance at 200 people, they do many shows around the country (so one is probably near you) and they do the shows over a weekend. Basically they are trying to keep it small, intimate and affordable. People must like it, since most shows apparently sell out. Basically they are doing (on a commercial level) what Deeper in .NET and Heartland Developers Conference have been doing via user groups.

NFJS has historically been a Java show, but they recognize that most organizations today use a mix of Java and .NET. They also recognize that the two platforms are more similar than they are different. Because of this, the NFJS organizers are building a .NET component to the conference.

I must say I went with some trepidation, since not all Java people are tolerant toward anything Microsoft (I’m being polite here). But I had a blast. Sure there were a couple misguided sneers here and there, but by and large the people attending the show are serious technologists who want to do the best job they can with the best knowledge and tools they can find. And that kind of person is really fun to talk with irregardless of their preferred development platform!

What I found most interesting about the NFJS attendees is their focus. In a Microsoft conference the focus is all on Microsoft. What is Microsoft going to do, what are they doing and why’d they do what they did? The NFJS show isn’t vendor-focused though, so the attendees were more interested in industry trends rather than vendor actions. People wanted to know where the industry would be in five years, what is going to replace Java now that it is old and boring (Ruby and Groovy seem like popular options), what is the real story about integration between BEA, IBM and yes, even .NET.

There were discussions about whether software development is art or engineering or both (thanks to a keynote by Dave Thomas). But I can’t remember a conference where there was serious debate about whether software is trying to model the real world or is a mathematical proof of a process. The geek-o-meter at this show is very high! :)

I’m doing at least a couple more NFJS shows in Boston and Minneapolis (here’s my speaking schedule), and I’m really looking forward to them!

For user groups interested in organizing day-long events like Deeper in .NET, I strongly recommend it. You can work with your local Microsoft DE, and local consulting and technology companies to get sponsors to cover the cost. Get involved with INETA, as they can help you get speakers (they covered the cost of getting me to Milwaukee for instance). Make it happen – these events are great!!

In this article, Bill Vaughn voices his view that DataAdapter.Fill should typically be a developer's first choice for getting data rather than using a DataReader directly.

In my VB.NET and C# Business Objects books I primarily use the DataReader to populate objects in the DataPortal_Fetch methods. You might infer then, that Bill and I disagree.

While it is true that Bill and I often get into some really fun debates, I don't think we disagree here.

Bill's article seems to be focused on scenarios where UI developers or non-OO business developers use a DataReader to get data. In such cases I agree that the DataAdapter/DataTable approach is typically far preferable. Certainly there will be times when a DataReader makes more sense there, but usually the DataAdapter is the way to go.

In the OO scenarios like CSLA .NET the discussion gets a bit more complex. In my books I discussed why the DataReader is a good option - primarily because it avoids loading the data into memory just to copy that data into our object variables. For object persistence the DataReader is the fastest option.

Does that mean it is the best option in some absolute sense?

Not necessarily. Most applications aren't performance-bound. In other words, if we lost a few milliseconds of performance it is likely that our users would never notice. For most of us, we could trade a little performance to gain maintainability and be better off.

As a book author I am often stuck between two difficult choices. If I show the more maintainable approach the performance Nazis will jump on me, while if I show the more performant option the maintainability Nazis shout loudly.

So in the existing books I opted for performance at the cost of maintainability. Which is nice if performance is your primary requirement, and I don’t regret the choice I made.

(It is worth noting that subsequent to publication of the books, CSLA .NET has been enhanced, including enhancing the SafeDataReader to accept column names rather than ordinal positions. This is far superior for maintenance, with a very modest cost to performance.)

Given some of the enhancements to the strongly typed DataAdapter concept (the TableAdapter) that we’ll see in .NET 2.0, it is very likely that I’ll switch and start using TableAdapter objects in the DataPortal_xyz methods.

While there’s a performance hit, the code savings looks to be very substantial. Besides, it is my opportunity to make the maintenance-focused people happy for a while and let the performance nuts send me nasty emails. Of course nothing I do will prevent the continued use the DataReader for those who really need the performance.

Sahil has started a discussion on a change to the BinaryFormatter behavior in .NET 2.0.

Serialization is just the process of taking complex data and converting it into a single byte stream. Motivation is a separate issue :)

There are certainly different reasons to "serialize" an object.

One for what I do in CSLA .NET, which is to truly clone an object graph (not just an object, but a whole graph), either in memory or across the network. This is a valid reason, and has a set of constraints that a serializer must meet to be useful. This is what the BinaryFormatter is all about today.

Another is to easily convert some or all of an object’s data into actual data. To externalize the object’s state. This is what the XmlSerializer is all about today. The purpose isn’t to replicate a .NET type, it is to convert that type into a simple data representation.

Note that in both cases the formatter/serializer attempts to serialize the entire object graph, not just a single object. This is because the “state” of an object is really the state of the object graph. That implies that all references from your object to any other objects are followed, because they collectively constitute the object graph. If you want to “prune” the graph, you mark references such that the formatter/serializer doesn’t follow them.

In the case of the BinaryFormatter, it does this by working with each object’s fields, and it follows references to other objects. An event inside an object is just another field (though the actual backing field is typically hidden). This backing field is just a delegate reference, which is just a type of object reference – and thus that object reference is followed like any other.

In the case of the XmlSerializer, only the public fields and read/write properties are examined. But still, if one of them is a reference the serializer attempts to follow that reference. The event/delegate issue doesn’t exist here only because the backing field for events isn’t a public field. Make it a public field and you’ll have issues.

In .NET 1.x the BinaryFormatter attempts to follow all references unless the field is marked as [NonSerializable]. In C# the field: target provided (what I consider to be) a hack to apply this attribute to the backing field. It also has a better approach, which is to use a block structure to declare the event so you get to manually declare the backing field and can apply the attribute yourself.

The trick is that the default behavior is for the backing field to be serializable, and things like Windows Forms or other nonserializable objects might subscribe to the object’s events. When the BinaryFormatter follows the references to those objects it throws an exception (as it should).

I made a big stink about this when I wrote my VB Business Objects book though, because I discovered this issue and there was no obvious solution. This is because VB.NET has neither the Field: target hack, nor the block structure declaration for events. I was forced to implement a C# base class to safely declare my events.

I spent a lot of time talking to both the VB and CLR (later Indigo) teams about this issue.

The VB team provided a solution by supporting the block structure for declaring events, thus allowing us to have control over how the backing field is serialized. This is a very nice solution as I see it.

I am not familiar with the change Sahil is seeing in .NET 2.0. But that is probably because I’ve been using the block structure event declarations as shown in my C# and VB 2005 links above, so I’m manually ensuring that only serializable event handlers are being traced by the BinaryFormatter.

But I should point out that the C# code in the example above is for .NET 1.1 and works today just as it does in .NET 2.0.

A reader commented on my previous post about patternshare.org:

The content on patternshare.org is weak. I don't think the content will ever be as strong as the books that the Authors are trying hock.

It seems like every good design choice these days are being labeled a "Pattern". Quite a shame.

Don't misunderstand... I'm a huge pattern evangilist.

We must keep in mind that patternshare.org can not replicate the patterns from the books. That would violate copyright law. The goal of patternshare.org is to be an index, to make it easier for you to figure out which books to buy and/or where in those books to find interesting patterns. That is an admirable goal and one that I think patternshare.org can accomplish.

In 50 years (or whenever it is that copyrights run out) we can put all the book content online and then we won’t have “weak” content. But up to that point I’m afraid we’re kind of stuck with the reality that the patterns are in books, and the books are copyrighted and that’s that…

Regarding the comment that "everything is being labeled a pattern" I agree. It is the current over-hyped trend in the architecture/design space - competing only with SOA.

But I think that the current pragmatic value of patterns is to provide an abstract language we humans can use to discuss our software designs. A language better than we have without “patterns”. Regardless of whether some of these "patterns" are really patterns or not, the fact is that the collective effort of all these books and articles is providing us with that common language - and thus is allowing us to communicate at a higher level than was possible even 3-5 years ago.