Last night I was working on something and suddenly found myself needing about 30 really simple ActiveRecord classes. I figured it was about time to stop writing these manually each time.

Looking at the CastleProject.org site, and seeing that the status of ActiveRecordGenerator was frozen, I briefly considered writing my own little tool (or just modifying ActiveRecordGenerator as needed) to do the job. After another 10 minutes, I finally broke down and made a CodeSmith template (we've got CodeSmith, but for some subconscious reason I keep avoiding using it.)

This was fairly straightforward, and after 20 minutes or so, I had the template I wanted, and started generating classes. After another 20 minutes I had added some things I missed the first time and everything was great.

After completing this, I looked at what I had done, and found myself thinking: this is alot of cruft.

Let me mention that all 30 classes had basically the same set of properties. I briefly considered writing a generic class, but didn't think there would be a way to get the name of the class into the '[ActiveRecord("MyTableNameIs")]' attribute. That, and a small handful of special rules, were the only things different about these classes.

I was thinking: A lisp-like macro would have been really useful. Why don't we have lisp macros in OO languages like C#? I've always fealt (but not agreed) that it's because OO leads you to composition instead of code generation. I could have written one base class with the properties I wanted, then 30 derived classes with the right names and attributes. That is still too much typing, though, and I would have used code generation anyway. I chose not to relate these classes, as they are not really related in this domain anyway, only functionally and structurally related.

I am not sure what the best answer to this type of design problem is, but I know I haven't found it. Code Generation is a jack-hammer in the face of the problem of code duplication caused by imperfect design. It gets me through the barriers, but the barriers were trying to tell me something.

Frameworks and tools (like ActiveRecordGenerator, or even better - Streamlined) that generate applications based on meta data are becoming very popular. Are these tools just reactions to the lack of good DSL tools or lisp-macro-like facilities - i.e., why am I writing my C# application in Code Smith templates and not in C#?

 

I went to dotnetusers.org's meeting tonight for a WCF presentation. The presentation wasn’t as deep as I had been hoping. I am trying to get back into this stuff and need some oomph. After seeing more and more really awesome presenters, I am really starting to hate power point.

There were a few more people than at ssound.net in Olympia, but if we keep things going at ssdotnet, we can take 'em.

Ted Neward was there and some other people I almost recognized from somewhere.

Jason Haley indicated he was going, but I don’t know what he looks like (ok, look, there is a picture here…but I don’t think I saw you.)

For a large chunk of my developer career (from about 1999~2004) I was really, really interested in distributed systems. I remember when the ATL developer’s mailing list morphed into the SOAP mailing list (or maybe I morphed into someone reading the SOAP mailing list.) I loved COM+. I loved web services. When I first heard about Indigo, I was soo excited.

Then something kind of weird happened. I started seeing people actually building apps with XML Web Services. They sucked.

The last straw is still unfolding into my life. At work we are doing this huge, uber-high-stakes integration project with a third party application. The API blows chunks. I don't (really do) want to get into details, but someday, after I have filled my lungs with this, I will have some stories to tell, I am sure.

This is a high-visibility project and my boss is heavily leveraged. He (we) need this to work out well - but I just know something is wrong. All the signs are there. The first sign was when I saw they had a XML Web Service (...kind of thing....ahem) that returned a "cursor" (and I knew the backend database was Oracle...hmmm...cursors...Oracle...web services...)

Other signs:

• They've been talking/planning/meeting 20+ hours a week about it for almost a year, but ask any two people and you'll get 3 different answers about what they are doing and how it all works. The tracking error grows geometrically as you move away from the source.
• Every developer looks at the service interface and sees something different (I call them bad XML web services, but someone else might call it floor wax.)
• I sense a lot of apathy from some of the people that are supposed to benefit from this.

reduced:

• Lack of vision
• Lack of cohesion
• Lack of perceptible benefit

So what does this have to do with WCF? The reason I am having trouble getting back into this is that it is too far gone from reality. 3 years ago, it kind of sounded plausible that we would have all these people building loosely coupled apps with WS-* and the hundreds of specifications and rules they would have to learn to make it work right. Now...it frankly sounds kind of naive.

WCF makes it really easy to do things really right for Windows developers. For java developers there are things like this too, but when you read white papers from IBM or Oracle, you just know they aren't talking about exactly the same things. There is some kind of disconnect that keeps everybody from agreeing on things and just building stuff - and in the confusion, vendors like ours are born.

Being able to move up the food chain by claiming to support, "integrated, enterprise, solution-oriented, xml, distributed, _standards_based_, web services," is a boon to the sales forces of companies like this. Before they had libraries based on COM, Java, maybe perl or something, the sales guys didn’t know what any if that meant, and everything sort of worked. Nowadays you can put lipstick on a pile of XML pasta and sell it as a feature. All the sales guys “know” what that means, but not the developers.

I know we will be using WCF to unify how we build distributed apps in-house and I know some vendors will do the same thing. But we still have a long ways to go in integrating applications.