Data Binding

Topics: CAB & Smart Client Software Factory
Jan 9, 2006 at 4:42 AM
originally posted by: aaguiarz

I noticed that you are not using data binding in the forms. Why?
Jan 9, 2006 at 4:43 PM
originally posted by: BradWilsonMSFT

I'm going to preface this with a couple of caveats that will likely be repeated often: this is a work in progress, and may not reflect final architectural goals because of the way we develop software.

With that in mind... I presume your question is about the right hand side of the application window. What are the advantages you'd see to using data binding in this scenario?
Jan 11, 2006 at 1:31 AM
originally posted by: aaguiarz

OK, let me rephrase it...

Is there something in the MVP pattern that makes using databinding difficult?
Jan 11, 2006 at 6:50 AM
originally posted by: aras03k

I would have to speculate yes. Wouldn't the view circumvent the presenter if it used databinding directly on the model?
Jan 12, 2006 at 9:53 AM
originally posted by: BradWilsonMSFT

As far as using data binding for editing, I'd say that shouldn't be done in MVP. You need to communicate changes to the presenter, not to whatever data representation it gives you (I won't call this the "model", because it is not necesarily the model used by the application).
Mar 11, 2006 at 3:09 AM
originally posted by: GiriT

A lot of this debate hinges on what is appropriate for the application you are building, the level of complexity you want to incurr (and maintain) in its architecture and frankly how long you have to deliver it!

MVP, from what I can see, is all about separating out as much of the code from the view as possible so that you can:

  • easily swap out one view for another
  • test the presenter (the logic for the form) without having to have a view.
  • be able to further divide tasks out to multiple developers by having finer grain artifacts

In terms of data binding I think that a read only view is a fine candidate for using databinding, a lot of people baulk at the words "data binding" because they are thinking about technologies and techniques going back to VBn days.. The reality is a lot of effort has gone into making data binding in 2.0 pretty good, especially with its ability to bind to an object. The code you would have to manually create to map attributes to properties of forms (because you have to do it somewhere) gets generated for you... Now if you want to write lots of code, and then test it, and then debug it and then maintain it, fine... If you would rather let the tool generate the code for you and live with some of the architectural limitations that that might create in return for NOT having to write, test, debug, maintain then its a choice that you have to weigh up for your project..

One last thought.. its no good living in the delusion that increased layers of abstraction free you from the impact of an entity level change.. the hard reality is that most of these kind of changes ripple up from the database schema all the way through to your form (if they didn't why are you making the change?). So having the view "know" about the entity (data bind on the view) is no more fragile than having the presenter (and the hand crafted mapping code) know about the entity either...

thoughts?....
Mar 18, 2006 at 9:51 PM
originally posted by: edwardsmit

My opinion, is that the majority of the time the UI is an updateable view of the Model. That view must provide the user with cues about the kind of data wanted by the model, validation of input is one such cue. In order to facilitate this, I make sure that the Model's properties verify that the values being set adhere to the constraints and throw an exception in case they don't. By Databinding the View (either a composite UserControl or a Form) to the Model and databinding an instance of an ErrorProvider to that same DataSource, I automagically get my Invalid Field cues provided by the ErrorProvider, containing the ToolTip I've put in the Exception.
I've always viewed this as an MVP implementation where the P is implemented by the combination of the DataBinding and the ErrorProvider infrastructure. On top of that, I also get the benefit that my View gets updated when the Model get's modified by another Thread, also thanks to the DataBinding infrastructure and a little help of the PropertyChanged event. This gets very handy when the Model gets filled by a call to a ServiceAgent. The MVP possibilities are still intact except the ability to independently test the Presenter, but hey that's all infrastructural code, and we all know that that is the code you shouldn't unit test. Both the Model and the View can still be unit-tested.
Mar 19, 2006 at 12:48 AM
originally posted by: aras03k

edwardsmit,

We have also considered this solution as one way of achieving databdining support. My concern is you loose the ability to replace the view on top of the same presenter. This would be useful in situations where you need to reuse a certain view in another context, but the layout needs to change slightly or some of the fields might be omitted. I'm also not sure if directly mapping gui controls to the model is always the best approach. In my web service based smart client I would have to invoke an "expensive" server roundtrip to support the feature Edit/Undo.
Mar 19, 2006 at 2:18 AM
originally posted by: edwardsmit

It depends how you define "directly mapping" :-) The way it's done with a Presenter is that you define a specific class which performs the binding between the View and the Model. The way I suggest to implement it doesn't deviate from that principle, but rather than writing a specific class for it, I'm using what's already there, the databinding support. It's the DataBinding which provides my level of abstraction, and acts as the controller. In most of the cases I've seen, this is enough. I've got my Parse and Format to do transformational stuff, and my Model makes sure that it can only contain the values that are allowed.
It's easy to implement (once you understand it), it's testible, there's separation of concerns, it's fast, it's supported.
You can replace the views, and as soon as you need to use the view in another context, it's more than likely it's another view that you have to build anyways.
Hey, I'm not religous about this, but I'm all for using what's already there. :-)