One illustration - I had a sort of "deja vu" feeling looking at SmartPartInfo structure, because this is one of the things I felt I successfully resolved while working on my company's application framework: a class that carries enough information to allow the infrastructure to create a control and display it in a standard way: in its own window or as a part of another window. Be honest, how many times have you wished you could display a form within a form? With CAB the programmer has the option to say "I don't care, just show this control, you know, in a standard way".
What depresses me somewhat is the fact that all this time people have been trying to create the same things in a same way. And the reason for this is that the same infrastructural deficiencies were troubling all of them, and that the solutions were obvious enough. I mean, for chrissakes, why do I have to instantiate a container form for to show a control, why can't I just display the control directly? Why can't the infrastructure do this for me? Why can't it track forms and prevent me from opening duplicates? I can easily provide it with an ID to do this. Etcetera. And then you end up with a bunch of forms which all have a single control inside, but if you want to access the control from the outside you either have to make it public (which is Bad Practice) or write accessor methods on the form (which is TEDIOUS).
Depending on your ambition, developing an answer to these questions can be a huge effort (at its simplest form, it's not at all easy), so you're forced to either stamp out mind-bogglingly dumb code or roll up their sleeves and build a solution to it. Oh, yes, but it's not that simple: if you want to instantiate "some control" (e.g. depending on parameters or context), you can't do it in an officially endorsed way. One could use reflection to make things easier - but dey say not to use reflection 'cause it slow and not type-safe. So we obey: but lo and behold, CAB is built on reflection! And it's the only logical solution, if you ask me: you really need to have a way to replace certain types with certain other types (which is effectively overriding whole classes, is it not?) You really need to have automatic coupling of events with event handlers if your code is going to be modular. You really need command objects that can be fired from whatever UI component can fire them. Etc. The problem here is not reflection, the problem is C#, it's stuck trying to be both type-safe and dynamic, and all that using C syntax rules.
I feel we're still using prehistoric mechanisms for validating our code. We have ultra-powerful visual tools that can figure out by themselves what code to generate where, what references we need to compile the code etc, and they tell us of errors in code while we're typing it. Yet, none of these advanced techniques exist in the compiler. I mean, why isn't the compiler aware of the attributes the ObjectBuilder is aware of? Why couldn't the compiler check if I'm using the CAB attributes in a proper way? Why couldn't it emit dependency injection code at compile time, why does the infrastructure need to employ reflection at runtime and slow everything down? And - well, why the syntax with attributes in the first place, why not a real language feature? Attributes are not neraly structured enough to provide really complex metadata we require today. Although the dependency injection attributes look somewhat cool, using strings to identify event topics is really ugly. That's probably because you can't provide anything other than simple data types as attribute parameters.
A case in point:
[State("customers")]
public List Customers
{
set { customers = value; }
} Now, this is quite cool, having your property automatically bound to a value in the shared state... But it's also contrary to all type safety principles Microsoft boasts with when talking about C#: who is to check if the state really contains a "customers" item of type List
We either need a programming language that will support CAB-like features from the ground up, or a development environment that will be CAB-aware so we can't make mistakes like mistyping event topics. From what I hear, some such languages exist and are quite popular, but I haven't heard of an IDE (although I didn't look much). Now I'm not being unrealistic here: just like in bridge building (a profession that is very popular lately in the software development comunities ;)), a comprehensive infrastructure makes your job easier, but you have to know how the infrastructure works. We shouldn't expect a magic wand IDE or compiler, but some consistency would make things much more predictable.
I suppose the IDE will be what Microsoft pushes for. Just like the Enterprise Library 1.0 became part of .Net 2.0, the new application blocks will probably be a standard part of a future .Net framework, and one day (hopefully) there will be design-support for them. For example, it would be nice if the form designer could detect ObjectBuilder-aware classes, and generate ObjectBuilder calls to instantiate them. Also, the design-time environment should be coupled with the dependency injection framework so that components could be properly instantiated in the designer.
What I am sure, though, is that Microsoft will never manage to cover all the possibilities for visual tool usages. Look at what they're doing now with windows data grids: they have three instead of one, one of the three is buggy and one obsolete, and in WPF there won't even be a data grid (which is probably good because it would have been the fourth one). Compare this to third-party data grids which look like space shuttles, and you'll see what I'm driving at (ok, data grids are not typical average components, but they're at the extremely successful end of the same category).
So Visual Studio Orcas could be a third-party component developer heaven (that is, if you abstract the terribly buggy Add-in API which will probably stay the same). There we'll have a standard way to represent a database model using LINQ components (which for ex. means that the IDE could automatically generate code for filling all those godawful stupid combo boxes), an ultra-advanced vector and 3D graphics interface (which means an easier way for develping advanced visualisation and an unlimited room for third party controls because WPF will have next to none), and CAB (along with existing data-binding and similar mechanisms) will provide a base framework for integrating various components. And then we'll start waiting for whatsitcalled (Hawaii?) where they'll finally have the tools finished. Are you prepared to wait for 2010? I've already made my own modelling component, and in the next couple of days I'll be using the detected foreign keys to automatically fill the combo box items.
Nevertheless, it will be interesting to see where it all ends. My guess is that all of this is only a prototype for a future environment which will be fundamentally different. We're currently just trying out to see how it all works. Once we have the mechanisms and requirements figured out, we'll see what is the best way to implement them. And at that point we'll be able to take for granted much more than we can now, from a vector-based interface to data-modeling support built into the framework. But will Microsoft be prepared to write Visual Studio from the ground up? I don't think so. So, third party developers, start making your own ultra-futuristic IDEs. But please: this time, don't everyone write the same code ;).
