Irony of frameworks and magic

I’ve been looking into .Net the last few days. Especially the interplay between managed and unmanaged code relating to COM (COM+) components. The most amazing thing is how much thing the framework will do for you implicitly. E.g. there is no visible difference in the source between instantiating a COM component and instantiating an object of a class. From a run-time perspective there is a huge difference of course, but the source for the managed code looks the same. No use of CoCreateInstance() anywhere!

I can clearly see how this is an appealing feature from the coder’s point of view. It means the deployment can be decided very late. You wan’t class A to be a COM component? Sure, why not? All it takes is adding an attribute to a class, that can be done at the very late in development. In short the COM-isation doesn’t have to happen until the very last step. Decision time is pushed as far back as possible. Cool! Right?

Explicitness does have a lot going for itself:

  • It makes the developer think about what he’s doing.
  • It also forces some things to come up to the surface early on.

In the example with managed COM components the thing that doesn’t surface until it’s too late is access control. When pushing the deployment decisions to the end of a project there is little incentive to put access control in the code during development. By the time it’s clear where the access control is needed it’s too late to put it in, unless you want to blow your dead line.

So, in the end the lack of explicitness will require the developer to know more about the framework and how it works… the irony is that this is what the magic was put there to prevent.

Leave a comment