Is data binding fundamentally incompatible with MV

Question

Data binding establishes a direct coupling between the view and the model, thereby bypassing the controller. Fundamentally this breaks with the Model-View Controller architectural pattern, am I right in thinking this? Does this make data binding a "bad thing"?

Edit: As example, angular claims to be a MVC framework, yet one of its main features is data binding.

Answer 1

In my opinion Data Binding can be a valid implementation of the MVC Pattern since the data binding mechanism itself acts as the controller in that case.

For example in the mentioned angular it seems like the $watch function is a shortcut to implement features that are typical Controller responsibilities and features in an MVC-style way.

So in my opinion data binding is an evolution step that implements best practices learned by implementing classic MVC controllers.

UPDATE

But in original pattern sense I would characterize data binding more like MVP or Passive View.

But the differences aren't that sharp in my opinion since it always also depends on your UI technology.

Answer 2

Actually, when your data is abstracted properly, the act of pushing the content of your models to your UI is a repetitive task that normally lead to some kind of "helpers".

Let's say to push a list of items to a combobox. This is not necessarily part of the controller as you may want to share such functionality. Also pushing the value of the control (to keep it simple, let's say the text of a textbox) is repetitive and bi-directional.

Also here you repeat your self (think of DRY) and do the same thing over and over again.

That's exactly the point where databinding comes into play. This can take over the tasks that anyway are identical for simple controls (checkbox, textbox, combobox). For grid control and the like it may be specific.

Have a look at mvc & databinding: what's the best approach?. Here I discuss what could be the optimum when using databinding in combination with MVC.

Answer 3

Data Binding does not directly couple the view and model, so it is not a Bad Thing®. It is an integral feature of the MVC architecture, which the GoF Design Patterns book describes succinctly in chapter 1.

MVC decouples views and models by establishing a subscribe/notify protocol between them. A view must ensure that its appearance reflects the state of the model. Whenever the model's data changes, the model notifies views that depend on it. In response, each view gets an opportunity to update itself. This approach lets you attach multiple views to a model to provide different presentations. You can also create new views for a model without rewriting it.

It's a common misconception that MVC is a layered (3-tier) architecture. It is not. The model updates the view(s) directly. But this does not mean the two are coupled! A publish/subscribe design keeps the model and view decoupled.

This more general design is described by the Observer design pattern.

Answer 4

Not necessarily, since you don't have to bind your Model objects to the view.
What I usually do is create simple DTOs (or Presentation Objects) that contain only the data I want to display, and that's what the View layer displays.
In that case, the Controller retains its function as a translator between actions performed on the DTOs and actions on the underlying Model entities.