Windows WorkFun

Here's a lovely thing about windows workflow.

Suppose you want to pass in some input paramters.

That's great. And WF supports it! You create a generic dictionary of

like this:

Dictionary<string, object> ret = new Dictionary<string, object>();

now the WF framework will dutifully walk through the Dictionary, and for each string/key, it will use .Net's reflection to look for a public workflow property with the same name.

So if you create a workflow and, in the code of the class, you add:

Public string thisIsAHack

{ get { return "hack";}

set (someVar = value;}

}

then you add a Dictionary entry like this
r.add("thisIsAHack", "someDummyValue");

and if you pass the Dictionary to the workflow , then ("*ding*") the workflow property will be populated.

Ok... on one level that sounds cool.

On another level, it makes me say "what were you guys *THINKING*?"

First of all, there is no validation at all. It's very loosely coupled. So in many ways, it's a throwback to the old JScript days when all variables were "var x =" . There's no strong typing. So you have no clue until runtime whether or not things are going to actually.. you know... work? The least they could have done was provided a tool to do easy type-checkng on the inputs. Or a "is this ok" method we could call before hand that would do a test and return true/false, so we're not stuck with a runtime exception.

But, ok.

The second (minor, I'll admit) thing is that they have to be public properties. The public part I kind of understand (although it throws out data protection for things in the same namespace). But the *property* part annoys me.

I'll be honest. I love properties. I get it. But it drives me *UP A WALL* that the coding standard is:

public string SomeProp

{

get{ return _someProp;} set {_someProp = value; }

}

that code and *ZERO* value and just clutters the source. I mean please. Properties are great if you want to do some special logic with the variables. But come on. What value does it add to put a wrapper on top of the accessor, that just passes and sets the value anyway?

So far, it's not so terrible. But here's the awful part.

Ok... first of all, the workflow classes are "partial" classes. Partial classes are a sin. I hope Microsoft repents from this before God smites the world because of it. Or at least the guys who invented OOA/D smite them.

Honestly, I think Micorsoft has never liked object oriented development. All their products talk about it

I remember when VB4 came out. I still have the box. Right on it, it says that it's an "object oriented RAD" tool. Forget the fact that OO and RAD are nearly polar opposites, VB4 was about as OO as ... well... C. Yeah, it had a keyword "object" but no inheritance or dataprotection, and only had polimorphism because the data was not typed. I mean, please.

We've seen this a lot. Databound Grid controls. Need I say more? That's about as non-OO as you can get. Oh, and MVC? well, it's in the docs, but you have to work pretty hard to do it.

Alright. So partial classes are an abomination. It is an oximoron to anything object based. The whole point of a class is to put all the logic and values together. Partial classes are.. well.. not classes. They're pieces of things. At my last job, I told my team that if I ever ran across one in a code review I'd slap the developer.

(note to self: *remember to breathe*)

Now here's where it gets good. The partial class workflow is a partial to... what? Oh, you can't tell. MS locked that down. So, suppose you're walking along and you add a public (*grumble*) property to your part of the partial class. And suppose there's a name collision of some weird type with the other side of the partial class. Or.. even bettter, suppose there's a name collision with something in the hierarchy tree that.. oh yeah.. that's right, you can't see.

When you dutifully add the item to the input dictionary

r.add("Site", "somesite");

everything is great. But when you create the workflow, you'll get a runtime error with this very helpful exception message :

"Ambiguous match found".

Microsoft very clever doesn't tell you *which* property caused the ambiguous match, by the way. It's similar to some of the SQL server errors I've seen where they tell you there's a data missmatch on an insert, but don't bother to mention which column is actually mis-match.

Gee. thanks guys.