April 27, 2007

...Learn TDD with Codemanship

AJAX Tool Triggers 2-tier Flashback

What is it exactly that I have against data binding?

The mere mention of it sends cold shivers down my spine. Perhaps it's the flashbacks to the days when I had to rein in the excesses of teams of Visual Basic developers who connected their databases directly to Windows forms, culminating in the dreaded 16,000-line form class module. The other 2/3 of the application's logic was buried in almost totally unmaintanable SQL stored procedures. Basically, we had our classic 2-tier client-server set-up: clicking button X called stored procedure Y, which returned recordset Z which was then bound to UI widget W directly. People who couldn't write code loved it, and a whole generation of programmers who can't actually program was born, and many of them are still making very good livings today.

Or maybe it's the Duwamish Books debacle. Remember that? The wisdom at the time was that these 2-tier client-server applications were a very bad thing. You ended up with database-dependent code in your UI, and business logic in your database, and a general muddying up of the logic of the system across the two tiers, creating a whole new order of spaghetti code that would leave COBOL programmers blushing with professional embarrassment.

Architecture pundits like Grady Booch and Martin Fowler were telling us that the smart thing to do was to split the logic up into distinct, cohesive and loosely-coupled layers: so there was one distinct layer for the UI logic, and one for the process flow logic, and one for the core domain logic, and one for storing and retrieving objects, and so on. We used to call this multi-tier (or "n-tier") architecture. And it was good. We had gone from a 2-tier paradigm that was heavily dependent on relational data models and on procedural/structured programming to an object oriented, component-based paradigm where everything had its place and we could make changes to one aspect of the system with less impact on the others. We could "re-skin" our UI without changing the business logic, or swap out our database back-end without the rest of the code being touched. Life was good.

But Duwamish Books kind of screwed things up a bit. Most of us designer/developer types (people who are unlucky enough to have to implement their own designs - like me) knew that calling stored procedures and binding the returned datasets directly to the UI was VERY BAD FOR MAINTAINABILITY. The object oriented, component-based, multi-tiered approach was working much better and quickly becoming the industry standard approach for client-server systems - and especially for the a rapidly growing kind of client-server application that ran on web servers. So us OO, component-based, distributed, concurrent software programmers were quids in for a while, because this was just up our street.

Until along came Microsoft DNA and the Duwamish Books example project. DNA was multi-tiered architecture. Except - that it wasn't. Not really. The Duwamish Books example project illustrated how you could build an applictaion with a UI layer, a business logic layer and a data access layer, and still be effectively 2-tier. Whereas before one clicked button X and called stored procedure Y which returned dataset Z which was directly bound to UI widget W, in the DNA model clicking button X called a business logic component usually with the naming convention of simply the name of the stored procedure followed by BL for "business layer". This business logic component - which typically included no actual business logic - then called a data access component, usually following the namking convention of the stored procedure name followed by DL for "data layer". This component then called the stored procedure, and returned the resulting recordset to the BL component, which duly ferried it back up to the UI, which was then bound directly to it in the aforementioned 2-tier style. You still ended up with most of your actual application logic scattered between the UI and the database - the two places you really didn't want it to be. Of course, there was the performance aspect to consider - namely that COM and COM+ applications performed liked dogs (on mogadon). We were advised to create "stateless" applications and use recordsets as data containers because of the overheard of creating lots and lots of COM objects to act as our domain model. In C++, Smalltalk or Java we thought little of it, but in VB, every instance was a drain on resources. DNA was a design paradigm borne out of the severe imitations of Visual Basic and COM. The real long-term solution was to replace COM with something simpler and more object oriented that would perform like other OO platforms like Java. Which is exactly what Microsoft eventually did. At the time, though, it didn't stop them from aggressively promoting the compromise as a "best practice", and many architects who cut their teeth on DNA systems have learned some pretty bad habits as a result.

To my horror, the army of programmers who can't actually program took DNA to their hearts, and Duwamish Books became their bible. I have seen dozens of applicatons where developers have literally copied and pasted from the Duwamish code samples. Nasty!

With .NET, Microsoft have been backing away a little from the DNA model. Their architecture and patterns mini-site tends to agree a little more with the likes of Booch and Fowler these days, though they still seem to have a disregard for the whole concept of a domain layer made up of Plain Old .NET Objects, which they should always be to ensure their maintainability and reusability.

But at least the old click button -> call stored procedure -> display recordset days are behind them.

At least, I thought so until I read this marketing blurb to promote their new Expression Web development toolset. A scripted, procedural language, fetching data from web services - the 00's equivalent of the stored procedure (with XSLT as the new SQL - only slightly less maintainable) - and binding it directly to the UI?

I can see a whole new generation of programmers who can't really program churning out a mountain of spaghetti code...
Posted 14 years, 6 months ago on April 27, 2007