views:

536

answers:

4

Hi I am rewriting my windows forms based application and I am going to use WPF. The application relies heavily on drag and drop techniques, in a very graphically environment. The uses "Design" reports etc. by dragging elements onto a grid, moving them, right click setting properies etc. all of which is saved to a database. Also control program flow by drawing flow charts, with routing and desicion making, all drawn on the form, and again save to a database.

Does MVVM lend itself to this kind of application, or am I trying to fit a round peg in a square hole.

Your thoughts are appriciated.

+4  A: 

MVVM lends itself very well to WPF. Can you do drag-drop with WPF and MVVM? Sure you can. Try searching for "WPF Drag Drop Behavior"

jesperll
+1  A: 

If you are looking for application maintianance and testability in the long term, sure you can do that stuff with MVVM and WPF. or else just go with WPF. MMVM initial learning curve is very steep.

Rey
Thanks, I think a mixture is in order. Try to stick with the MVVM principles for Commands, Binding and Database handling, but have some code behind to handle the more complex UI interaction.
Tim
+8  A: 

My take is to use MVVM, but not religiously.

I mean, use a model to your views, but also use some code behind when needed (drag&drop, double-click). Find a balance that helps your development, without driving you nuts.

Eduardo Molteni
Thanks, I think a mixture is in order. Try to stick with the MVVM principles for Commands, Binding and Database handling, but have some code behind to handle the more complex UI interaction.
Tim
+3  A: 

There are two really good reasons to go with MVVM:

  1. It helps you produce business logic and data access code that is more easily unit tested
  2. With very little extra effort, all of your UX should be easy to modify in Blend

As several posters have metioned, any eventing related to the UX can be handled in code-behind, but you should be exposing and accessing (read and write) data through your View Models for easy binding in your Views.

As for the extra effort I referred to in #2, you could easily add a static property to your App object to determine if the application is running versus a View being opened in Blend. If the View is open in Blend, leverage mock data instead of making data access calls. Here's some sample code that works for checking if Blend has a View open:

if (Application.Current == null || Application.Current.GetType() == typeof(Application))
{
    isInDesignMode = true;
}
else
{
    isInDesignMode = false;
}

Hope this helps.

Adrian Anttila
Thanks for your reply. I am not familiar with Blend. Learning Blend, WPF and MVVM principles may be to great a learning curve.
Tim