2.NET|!2.NET

Arthur C. Clarke once said "Any sufficiently advanced technology is indistinguishable from magic"

A few times recently, I've been in a situation where I just wanted to hold my head in my hands and groan "Noooo not again!! make it stop!!". Why? Well, because even after seven years of .NET people still don't get the idea of what advantages there are in fully embracing the framework's philosophies to create really great applications or components.

Imagine dumping a medieval man into the middle of London. Aside from the obvious initial shock, he'd become used to the idea that cars travelled about without horses attached to them, he could even learn to drive a car. He would become used to the idea of lighting without flames and he'd eventually become a consumer of fish and chips or MacDonald's burgers without necessarily understanding how it all happened or what made it all tick. After his short period of adjustment that went from screaming fits and soiling himself with fear, we would eventually get someone who can function just fine in the environment. Whether he could design a car or grasp the concepts of electricity would be however, a different subject entirely.

This is the sort of thing that happens when someone who is "expert" in 1990's technology gets hold of the concepts of third millennium .NET framework. They become a perfectly adequate programmer, able to apply their concepts of programming to C# or VB.NET and as long as their efforts are contained within a single sealed up application all is well and you can't tell the difference from the outside.

What happens however when that person, however innately intelligent they may be, applies 1990's ideas to .NET architectures and has the responsibility for creating, say, a huge data management framework of industrial proportions? You guessed it. A complete and total disaster that does nothing but make people groan with disbelief.

For me, the best aspects of .NET architecture are the ones that don't fall readily to mind, even if you're a world-renowned C++ guru and have 20 years of experience in your field. For example, the idea that your objects may take part in a design time environment. This was not even a possibility in the old world of C++ but now you should seriously consider whether your objects should at least carry the attributes such as Browsable, Description, Category etc. Furthermore, you should ensure that your object has a type-conversion strategy, should implement ToString correctly, provides a design-time editor, possibly a graphic editor, certainly a smart-tag, some designer verbs and so-on.

When designing an architecture today, we also need to look to current trends in data-binding. It used to be that tying an object to a GUI was a laborious process that required either brute-force, the preferred C++ method, or implementation of some pattern such as Model View Controller (MVC). Any remotely skilled Windows Forms engineer will immediately use data binding which neatly sidesteps these issues. However, the objects in question need to either provide changed events for properties or implement INotifyPropertyChanged. So, I hear everyone reading this beginning to say "Well, if the object is some deep part of a framework and not exposed to the GUI, why bother?" The answer here of course is that data-binding is no longer a GUI only issue. .NET 3.0 and 3.5 already has data binding that can take place between any two properties so that otherwise invisible objects can be bound. This is not only interesting for WPF maniacs but for anyone who has an object that receives input from another.

Finally, meta data and reflection coupled with new type description systems are so powerful that it adds vast new aspects to object orientation that are so outside the realms of the classic Encapsulation, Inheritance, Polymorphism triad that classes have ceased to become immutable definitions and have entered the realms of chimeric virtual objects that appear to be one thing when they are, in reality, something totally different.

If you're an architect and expecting to create a framework for your flagship product by all means pick .NET. Just don't go blundering about like a medieval peasant when you could be using magic instead.

What is the most important technology today?

With the recent release of .NET 3, Vista, WPF and the WCF systems one might think that the choice was large. However, from everything I've seen recently the most impressive and important technology of today isn't what one might imagine.

I think that there is only one truly outstanding thing in all of todays new technologies and in fact it's probably one of the most fundamental concepts because, after all, what we do as programmers is normally to enable our users to visualise otherwise cryptic data.

The technology of which I speak is, of course, data-binding.

As an architect of systems that manipulate otherwise boring and complex data, I've found that the method of databinding used can make the difference between a mediochre application and a truly fantastic one.

Data binding techniques are in the process of evolving. Look at the ideas in .NET 3.0 and you'll see that not only can the properties of data objects be bound properties of user-interface objects but just about any property may be bound to any other.

The binding mechanism is also becoming more of a presentation mechanism with the ability to add inline bi-directional conversions to the data so that raw data in a property may be treated in some way before it gets to the user interface.

These ideas may seem to be spurious at first glance. Who needs to bother how data binding works on a deep level? The answer may surprise more than you imagined. Why? Consider this.

For many years, since the early days of MFC and since the work of The Gang Of Four, design patterns have been talked about in the industry and many attempts have been made to implement them correctly. The Document-View model in MFC, the implementation of patterns such as MVC (Model, View, Controller) and more recently MVP (Model, View, Presenter) as used in the CAB (Composite Application Block) have all been the subject of various implentations attempts that were more or less successful.

My own experience with these classic patterns is that the ideas are usually great, the pattern has a logic and a simplicity that suggests that the implementation should render good results but the implementation, when left open to developers who use classic quick-and-dirty methods or just don't understand the architecture, usually falls short of expectations. One of the biggest problems I've seen in many applications is the blurring of the line between the boundaries of the pattern components. The way that we build applications, such as an MFC, Windows Forms or even WPF application, leave so much open to interpretation that developers will often write complex code into a form, dialog or user-control so that the functionality of what should be only, say the view, becomes part view, part controller, part model.

How does databinding solve this problem of interpretation of a pattern and the consolidation of an architecture? Well, the way we use databinding enables us to remove all aspects of business logic from the view and to move the intelligence of the application into the presentation portion where it belongs.

I'm in the process of preparing a number of articles on this subject which I will be posting over the next few weeks. If you're interested in the follow up to these ideas, watch this space.