Is data binding a bad idea?

Question

Another discussion (we've been having a lot of them these days!) in our work is whether data binding is a bad idea or not.

Personally, I think it is A BAD THING.

My reasons are thrice:

1) It circumvents my well architectured MVP framework - with databinding, the view communicates bi-directionally with a model. Ewww.

2) It promotes hooking up view controls to datafields at design time. In my experience, this leads to vital code (binding column A to Field X) being obscure and hidden away in some designer file. IMO this code should be explicit and in-your-face, so that it is easy to modify and see what is going on, without having to use a clunky designer interface.

3) Relating to Point 1) this direct binding makes it harder to isolate each component (view, model, controller/presenter) and unit-test.

The PROS are that it is easy to set up, and you can take advantage of some nice features (validation etc) which come with the plumbing already done for you.

But for me, databinding becomes much more of a hindrance when dealing with a large data-centric application.

Any thoughts?

Answer 1

@Point 1: Isn't the data binding engine the controller, if you really want to think in patterns? You just do not program it yourself, which is the whole point of using data binding in the first place.

Answer 2

As we say in the UK, "It's Horses for courses"

First off all, I agree with you! But...

For enterprise level applications, then spending the extra time on the system architecture, modelling and standards will give you a robust and sustainable system.

But it will take longer to develop (or at least longer to get to an initial release) and this may not be appropriate for every system or every part of the system.

Sometimes you just need to "get it done and done quick". For internal applications, back office systems and maintenance applications that are rarely used or very dynamic (the spec's change often) then there is little justification in building the Rolls Royce solution for this. It's better to get the developer spending time on the CRITICAL part of the system.

What you have to avoid / prevent is using these "one click framework" solutions on the MISSION CRITICAL area's of the system where the big transaction rate area's and where data quality and integrity is critical. Spend quality time shaving the milliseconds off on the most heavily used area's on the system!!

Answer 3

@Timbo:

Yes and no.... but from a TDD perspective I'd like to cordon-off each controller so that I can test it in isolation. Also, say we want to run each edit via an EditCommand (so that we support Undo, for example) - for me, this rules out databinding.

@Guy:

Yes, this is exactly my POV. For me, databinding is great for very simple apps, but we don't do any of those!

Answer 4

Hello Brian,

Another discussion (we've been having a lot of them these days!) in our work is whether data binding is a bad idea or not.

Personally, I think it is A BAD THING.

Strong opinion, but imho, you bring out all the wrong reasons.

1) It circumvents my well architectured MVP framework - with databinding, the view communicates bi-directionally with a model. Ewww.

I guess it depends on the implementation of the data binding. In the early years of my programming career, I used to do a lots of VBA for MS Access programming and Access forms had indeed this direct binding to tables/fields in database.

Most of the general purpose languages/frameworks have databinding as a separate component, do not use such a direct binding and are usually considered as a easy generic dropin for a controller in MVC pattern sense.

2) It promotes hooking up view controls to datafields at design time. In my experience, this leads to vital code (binding column A to Field X) being obscure and hidden away in some designer file. IMO this code should be explicit and in-your-face, so that it is easy to modify and see what is going on, without having to use a clunky designer interface.

I guess you are talking about the binding in WinForms? My experience with win forms comes from a long ago, so I might be pretty out of date here. It sure is a convenience feature, and I would strongly argue against it, unless you are writing really simple modal context CRUD style interfaces.

3) Relating to Point 1) this direct binding makes it harder to isolate each component (view, model, controller/presenter) and unit-test.

Again - assuming the view (a widget in WinFoms?) is tied together with databinding awareness, you are right.

But for me, databinding becomes much more of a hindrance when dealing with a large data-centric application.

Quite contrary - if data binding is implemented as an independent component (eg. bindings in Cocoa or JFace DataBinding, or JGoodies Binding), that acts as a controller between View and a Model, taking care of all the nitty-gritty of event handling and conversion and validation, then it is just so much more easier to use, change and replace than your custom controller code doing just the same thing.

The only downside of a general purpose data binding framework is that if the binding is off and/or misconfigured, the interactions between bound pieces are just notoriously difficult to debug due to the level of abstraction inside the data binding code... So You better not make any mistakes! ;)

Answer 5

I feel that in many frameworks, data binding is just an excuse to do things the easy way. It often results, as does almost any designer-generated code, in too much code which is too complicated and can't be easily tweaked. I've never come across a task I couldn't do just as well (if not better) and, in most cases, just as quickly, by data binding as by writing the code myself.

Answer 6

I have used databinding on large enterprise systems inconjunction with a framework. In my case it was CSLA.

It worked so well, and was extremly fast to get the view working. CSLA has lots of support for databinding and validation built in though.

If it breaks the MVP patturn, so what? if it works better and faster and is easier to manage. However, I would argue that it doesn't break the patturn at all... You can hook up databind in the presenter as it has a reference to the view and also to the model.

for example this is what you would put in your presenter and it would populate the list box or whatever control you want.

myView.list.datasource = myModel.myCollection;

• 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.

Alan

Answer 7

I've used databinding in some pretty large systems and find that it works pretty well.

Seems that I do things a bit differently from you though ...

... I don't databind to the model, instead to a dedicated view class that works as an adapter between the model's structure and what I need on screen. This includes things like providing choices for comboboxes & listviews, and so on.

... I never set up the binding using the UI. Instead, I have a single method (usually called Bind() or BindXYZ() that hooks everything up in one place.

My Model remains agnostic, knowing nothing about databinding; my Presenter sticks to the workflow coordinate it's designed for; my Views are now also simple classes (easy to test) that encapsulate my UI behavior (is button X enabled, etc) and the actual UI is relegated to a simple helper on the side.