Visual Basic 3 to Visual Basic 6 had many lessons to teach us. We did not as an industry learn these lessons, so we are in the midst of repeating them. One of the most important lessons was not to combine business logic and user interface code. Well DUH!
But, why not? I don’t mean to be rude, but I’d really like to shout in your face and make you truly understand. Fly to Tibet, climb a mountain and meditate in a hut for a month until you can answer that question. Why was it bad to combine business logic and user interface code?
Which of course you probably can’t answer because we would not have been so stupid, as an industry, to make these mistake second time around if we’d gotten it the first time. Combining business logic with any technology dooms it to be rewritten from the ground up when we get a new technology – and code is technology. DOH!
You cannot combine technology with business logic. You cannot combine code with business logic.
The shiniest, prettiest toys and languages are tomorrow’s legacy. Except for movements away from technology and code, everyone at Microsoft if building tomorrow’s legacy tools.
Don’t tell me it’s impossible to change, .NET had all the underpinnings to do metadata based code generation, rules engines, and other techniques in the first release. I’m not the only one who has been using alternative development techniques. Sure it’s hard. It’s really, really hard. It is too hard for you to do individually on your project. Changing our development efforts so fundamentally that we treat code as a necessary evil is such a fundamental shift that we need combined efforts, tens of thousands of man hours and significant leadership. In today’s world, leadership means either Microsoft or standardized, combined third party efforts. The third party has made great advances in niches, but no full-scale strategy. It’s time for Microsoft to step in.
Several things are happening right now. The current crop of technologies will teach your team the painful lesson that .NET is not an inoculation protecting your project from technology change. We have legacy .NET code. That sucks. The solid foundation of .NET actually does the opposite of inoculating your application from change. It speeds up the pace. Microsoft can build amazing new toys - so they do.
Another thing happening right now is that forces are moving behind the scenes to make it easier, or at least more standardized. LINQ to XML in Visual Basic offers XML literals which have amazing possibilities for code generation. Today, it’s better in some ways and worse in others to CodeSmith, but there is a real possibility it will unseat XSLT for complex generation. We need to work out a boatload of patterns which I’ll take many posts to cover, but you can get a peek in Beth Massi’s blog. Also on the horizon is Entity Framework which offers a standardized way to map to metadata. I’m spending time customizing the architectures for a talk at DevConnections, which will make a great blog post later. Other things just below the horizon will also make your generation easier in the future. The earth is turning.
Before letting the details of new technologies and code generation techniques start swirl around you like a blinding swarm of butterflies, take a deep breath and go to a mountain, or whatever you need to do to focus your breath on what business code is. It’s not plumbing, and it IS aspects of your UI. It’s not technology; it’s not anything repetitive between your classes. Encourage conversations about finding all of it, and let the rest of this decade be about isolating real business knowledge in all the places it resides: database structure, service contracts, test definitions, logic rules, workflow, business object code, validation rules, authorization guidelines, user interfaces, etc.