Data binding – Good or evil?

For years and years I’m trying to convince myself to like and love „Data binding„.

The term „Data binding“ (or „UI data binding„) in software development refers to a technique that binds two data/information sources together and maintains them in sync, usually UI controls and underlying (database) objects.

While the theory outlines many benefits like automatic storing/loading of form content and automatic data validation, my own experiences (primarily with Windows Forms in .NET) always lead me to complicated, unreadable code that took much longer and was much harder to debug than manual setting/reading of control values.

I even developed an clean and simple test application where I tried to use databinding in an insolated environment. I was not convinced either.

For a new project I am planning to try again to go with data binding.

After doing some Google search, I decided to sum up negative/critical articles about data binding in this article, since there are many positive postings about data binding (which seem to be mostly done by marketing guys of software companies).

So here are some postings:

Databinding is EVIL

Blog posting dated 2006 by a professional software developer who worked several times with data binding in the past and now decided to not use it anymore.

Quotes:

„Ok, I am officially done with databinding….“

„…Databinding works fine if you have very simple UI that does nothing but display data in a primitive way. Soon as you introduce complex and rich UI, databinding makes things much harder. If databinding is so easy to use, why is Brian Noyes‘ book „Data Binding with Windows Forms 2.0″ 696 pages?…“

„…Maybe I am old fashioned, but manually populating the controls will be much easier and more understandable. On top of that, the code will be more testable. Less magic is a good thing…“

This guy really speaks out what I feel 🙂

Is data binding a bad idea?

Posting on Stack Overflow about the pros and cons of data binding.

Quotes:

„…Also I would like to point out the databinding shouldn’t be taken as an all or nothing approch. Many times I use databinding when i have a simple and easy UI requirment to map to my object model. However, when there is special functionality needed I might put some code in the presenter to build up the view as I need it rather than using databinding…“

Benefits of DataBinding over Manually Querying / Adding to Control

Another discussion about data binding on Stack Overflow.

Quotes:

„…It can be useful to manually bind if you’ve got a complex input scenario. With databound input controls you can find that you only know you’ve got bad data when it hits the DB and throws an exception (badly formatted date/time, integer out of correct range etc). You can obviously handle this with the various validation / pre-commit events on the data controls but it can be easier (and more obviously readable) to just manually validate your input and post it when you know it’s correct…“

UI Databinding: alternatives and future

Yet another discussion on Stack Overflow.

Quotes:

„…The WPF binding although good is too complex, it combines features of XPath with normal .Net binding and is super flexible, but very difficult to debug when it gets complex, and also very longwinded – how many IValueConverter’s does one piece of code need?…“

Other resources

  • „Why Data Binding and the like are evil“ – Old VB6 article about data binding.
  • Why Databinding Sucks“ – Blog posting about data binding.

Of cource you’ll find many more resources on Google by querying for the appropriate search terms.

As a summary for my blog posting, I would love to get tons of comments about why I am right or, of course, why I am wrong.

Beispielprojekt für ADO.NET 2.0 mit Windows Forms 2.0 unter Visual Studio.NET 2005

Um mal in die aller einfachsten Grundlagen von Visual Studio.NET 2005 (Beta 2 mit June CTP) im Zusammenspiel mit ADO.NET 2.0 und Windows Forms 2.0 reinzukommen, habe ich in 2 Stunden eine kleine Anwendung zusammengeklopft (Download siehe unten).

Folgende Stichworte/Rahmenbedingungen:

  • Möglichst ganz wenig Code selber schreiben, möglichst alles die diversen Assistenten machen lassen
  • Typed DataSets verwenden
  • DataBound Controls verwenden
  • Windows Forms 2.0 verwenden
  • DataGrid verwenden
  • Microsoft Access 2003 Datenbank verwenden

Folgendes kam dabei raus.

Hauptfenster

Das Hauptfenster stellt schlicht eine Liste der einzigen Tabelle dar und hat die üblichen Schaltflächen für „Neu“, „Bearbeiten“ und „Löschen“.

Bearbeitungsfenster

Das Bearbeitungsfenster wird angezeigt um einen neuen Datensatz zur Tabelle hinzuzufügen oder einen bestehenden Datensatz der Tabelle zu bearbeiten.

Download

Hier könnt Ihr die Anwendung samt Quelltexten herunterladen (150 kB)

Zusammenfassung

Alles recht einfach zu benutzen. Für größere Projekte habe ich bisher immer selbstgeschriebene Klassen verwendet, aber im 2005er Visual Studio scheinen die Microsoft-Jungs nochmals einiges verbessert zu haben. Schaut vielversprechend aus.

Von den gesamten 2 Stunden habe ich übrigens 90% der Zeit dafür benötigt, eine einzige Zeile Code zu recherchieren. Und zwar diese hier:

BindingContext[shipsBindingSource].EndCurrentEdit();

Vielleicht hilft es ja mal jemandem Zeit zu sparen, wenn ich das nun hiermit dokumentiert habe.