Squeezing data to the surface

Database-driven web applications can be complex to build, but it’s amazing to see how much of this complexity is rolled into the execution of ostensibly simple things. Pushing data from the database to the interface is a prime example.

Take a typical Flash application using an XML-based web service written in C#/.NET using a SQL Server backend database. It’s a mouthful to say, but it is a typical server setup for a typical web application.

We’ll start the life of a piece of data as a row in some table in some database, somewhere. To extract this singular row, we may construct a SQL statement or a stored procedure, maybe passing the procedure the primary key value of the row we want to extract from table X. This SQL statement or procedure must be called by, say, a sqlCommand object in .NET, providing a sqlConnection object to open the database and, subsequently, a sqlDataReader object to extract the singular row from the database.

With the sqlDataReader open, we have a few options. We can be lazy, and just grab the data from the sqlDataReader object as needed and do as we please with it. Better programmers would, instead, write a custom class for that particular row of data. If it were coming from a table of users, we may call it a User object. Then, we neatly spit out the contents of sqlDataReader into this instance of a User object, thus producing a nice little .NET object that we can handle with better readability.

We now want to transport that object into Flash – we can either use something like .NET remoting or something free like XML to hand that data into our eagerly awaiting Actionscript code. Choose .NET remoting and we need to install components and setup our gateways. Choose XML and we’ll need to write an .aspx page to take the existing User object and serialize it out.

From here, we’ll need a corresponding way to retrieve that data on the Actionscript side. Again, better programmers will now write a corresponding value object in Flash – a one-to-one mapping of attributes from the .NET user object to ActionScript’s parallel version. If we use XML, we’ll need to write a parser and then feed the data into the User value object in Flash (not all that different a task from when we had to dig the data out of SQL Server and into .NET).

Now, in Actionscript, our trusty User value object needs to get to the surface. Perhaps it will bubble to the interface as one of several users in a dropdown list. In this case, we might employ the Flash V2 components and hook the value object to the dataProvider attribute of a ComboBox instance.

And, that brings us full circle – a single row of data in a database representing a user now appears in a dropdown box on screen. That data put on many different clothes along its journey – from database row to sqlDataReader object to an instance of a .NET User, then fed through a .NET gateway (or, alternatively, fed as XML into an XML object and then parsed…) into an AS2 User, before it bound itself into a combobox’s dataProvider and…finally, squeezed out onto the screen. Yet, along the way, nothing about it really changed. It morphed and molded itself through the pipeline of a tiered application only to remain its very self in a different language and in a different time and place. For the developer, all that work to put data “there” over “here” is pretty exhausting – even if it’s become commonplace for him after years and years of repetition.

Code generators help us get rid of the unnecessary squeezing of data from “there” to “here” and let us focus in on what really matters – how easy our applications are to use – how happy it makes the people that use it. The mental exercise of transforming data from “there” to “here” should be left to generators – they’re a helluva lot faster at doing it than we are, and, they never make mistakes. Code generators would make terrible user experience architects or psychiatrists – they have no idea of the meaning or value of what it is they do – they don’t know what is bad, better, or best. That’s where we come in.

When you combine the value that code generators provide with the idea that user interface components can be decomposed into 3 kinds of views, (those that represent either a data object, a collection of data objects or something static) you suddenly have a very powerful set of tenets from which to create applications. Let the generators build your data layer in Flash, let it wire everything underneath it accordingly, and then build your applications data-centrically. Every view has a home with a value object that’s been generated for you. You now can start piecing together the different parts of your application with data objects that the generator has provided you. In the end, the code generator’s done its job: Doing the dirty work to give you the tools you need to build your application without getting in your way.