While working on a rather large winform application, whose presentation tier is using Model View Presenter Pattern (MVP), my team and I discovered the blasphemy that is databinding when used with MVP. A lot of the developers on my team are pro-data binding as it makes their life easy on the first round of development for any given screen. What we found was that as the screen evolved and requirements changed (as they always seejm to do), the databinding began to become unweildy, and nasty. Complex page interaction between controls would quickly rear their ugly heads, and all of the sudden you'd be writing all sorts of code to support "most of the databinding" rather than just adding new interations.
I began plotting against databinding all together when the perfect argument popped into my head. Databinding breaks MVP. Think about it... If the view has knowledge of business objects, or worse updates them w/ new information it has garnered from user interaction, the presenter has be removed from it's primary interaction. Let us not forget my presenters job is to handle all the heavy lifting when it comes to dealing w/ data, model obects, and the interaction between the models services, and the view. Also, my presenter gives me a great way to unit test presentation logic. Once removed, how the heck to you unit test a view. It seems to me currency managment is a violation of MVP.
3 comments:
I think that your View needs to know at least what the data is going to look like in order to properly present it. When you lay out your GUI, you have implicit knowledge of the business logic and the data model of the application (that fits with that logic).
You can use data bindings with interfaces (you don't have to have your concrete implementations), the WinForms data binding is smart enough in its introspection to figure it out. Then you just assign your interface reference to the DataSource property of the BindingSource. If you are using a CurrencyManager, then the collection you are using is an interface reference as well (IWidgetList or IList<IWidget>).
If you want the Presenter to do all the heavy lifting, then you can create copies of the Application Model objects and pass those to the View, then whenever those change, figure out if you want to push the changes down to the Model layer or not.
Hi Garo,
I agree with you in part. If you are binding to an interface, the concrete object must have knowledge of that interface to implement it. If the interface exists on your presentation layer, then your business object is coupled to the presentation tier, (not to mention creating a cyclical relationship). This leaves you to creating presentation concrete's that have presentation interfaces. This would give you the seperation of concerns that we are looking for in a multitiered application, and allowing mvp to do it's thing. Now that being said, you would then need to do translation between said presentation object and it's corresponding buisness object as changes happened. This puts you in the same place or worse(as you no longer dealing w/ view events you are dealing w/ binding events). If the presenter doesnt do all the heavy lifting, it's acting as a pass through or worse an interpreter to identical objects.
Is this the Craig I think it is? This is little Sarah...looking for a way to talk to you and to Herry. I am now out of the USA and have some great Star Wars Stuff to send back... If you get this send me a shout back to my NYC Blog...or to my New Blog for my new Children's Book Publishing Company.
http://nycyouarehere.blogspot.co.uk/
http://zozocp.blogspot.co.uk/
And I now have a Facebook for the Company
ZoZo CP
SQ
Post a Comment