Does tight data binding always cost you more, in the long run?

Lately I seem to have been coming across a lot of software development issues relating to data-binding tools that implement a "tight binding" strategy, rather than a "loose binding" strategy. What does that mean? Well, a good example (that a colleague recently reminded me of) is the software tools that appeared in the 80s which would examine the structure of your relational database and generate a complete layer of C++ for creating, reading, updating, and deleting your data. For some C++ programmers, this was very appealing, because it meant not having to learn SQL, or otherwise learn anything outside of C++ (i.e. nothing new). In practice, it was often a disastrous approach, because databases need to change over time (and especially during the development of new applications), and every time you changed the database, you had to regenerate and recompile your C++ layer, which would change the API of the C++ layer and (often profoundly) break the rest of your code. I'm not picking on C++ in particular here, by the way, this is just one well-remembered example.

Now, the relational database community has had a long time to think about this problem (longer than, for example, the XML community has had to think about its problems). The solution that works is (a) you use OBBC/JDBC/etc. to query the database using SQL and retrieve a result set, and more importantly (b) you never write a SQL query that has "SELECT * FROM ..." in it.

Why is (b) so important? For those of you who don't know SQL, "SELECT *" indicates that you want retrieve *all* of the columns from a table. The problem is, you might know today what columns are in a table, but you don't know what columns will be there in future. Data changes over time, and that change is usually growth (more data added to the existing data). So if you use "SELECT *", you really don't know what data you are going to get back from the database. That is why the typically recommended practice on large-scale long-lived projects is explictly to select the data that you want, and nothing more, e.g. "SELECT NAME, ACCOUNT, LAST_TRANSACTION_DATE FROM ...". This is more verbose, but more reliable. Your code won't break if the database administrators have to add a new column to a table in the database.

In the XML world, there are a number of XML data-binding tools, and the most widely used of those tools are based on a tight-binding strategy. You take an XML schema and compile it into a set of classes (Java, .NET, etc.), which allows developers to pretend they aren't working with XML, because they have the comfort of working with their preferred programming language. I'm sure you've spotted the parallel with that old issue with C++ and databases

In XML, the equivalent of using SQL and a result set is to use a tool like XPath/XSLT/XQuery where you can specify the part of the XML data that you want, so you can ignore that data that you don't want. Analogously to the relational database example, this helps protect your programs from knock-on effects of changes to the XML structure. Don't bind tightly and broadly to the XML that somebody else controls. Select just the pieces of data that you need. If you really like the features that the XML data-binding tools give to you, then transform the externally controlled XML into your own locally controlled subset, using a transform (XSLT/XQuery) that selects only the explicit data that you need in your subset. You can then bind much more safely to that subset. You will need to go to the effort of producing a subsetted XML schema which you can bind to, but it's worth that effort in the long run.

It's not just XML and databases, either. Lately I've also been involved in looking at some code which uses .NET data-binding of data objects to GUI components. In particularly, I was asking why some of the application's private data was being shown to users in property boxes, when the user can't edit it and shouldn't even be able to see it (lest they use that internal data in their own applications and create a tight binding that the original application developers weren't planning for, and which might be broken by future releases).

I'm not a .NET GUI specialist, but I'm told that while the .NET GUI data-binding tools are a quick way to get a GUI in place, they tend to be "all or nothing", it's not straightforward to bind only a subset of a class's properties to a GUI component. If that's true (and if you are a .NET GUI expert, feel free to leave a comment), it's another example of overly tight data binding.

Tight data binding is a lot quicker to set up than loose data binding, because in tight data binding, you just bind to everything in sight, you don't have to take the time to carefully specify exactly what you do or do not want to bind to. However, if you don't take the time to specify exactly what you want, when the data changes over time (as it will), your application will break. Don't say I didn't warn you.