Which Design Pattern to use for MS Surface Apps (WPF)?

views:

102

answers:

+2 Q:

Which Design Pattern to use for MS Surface Apps (WPF)?

Background: I'm currently for my University creating some simple apps showcasing the possible educational potential of the Microsoft Surface. Their functionality falls somewhere between a basic demo app and a full-fledged production app.

Our hesitation with using MVVM or some other type of MVC is that, with the exception for the few apps that we have which are data-backed, most of our apps are deeply tied to their presentation (i.e. the Surface touchscreen). It doesn't seem logical to emphasize such extreme separation of business logic and the view in this circumstance.

Any ideas?

+2 A:

I've used MVVM with great success with Surface. MVVM is about modeling your views and separating out whatever logic is behind them. It doesn't matter whether that logic deals with databases or whatever. If you have a view, it is a view of something. Therefore that something should be represented by your view model.

HTH, Kent

Kent Boogaart 2009-08-27 19:02:24

+3 A:

The point of using an MVC of some kind, such as MVVM, is to eliminate that deep coupling between presentation and behavior. That kind of coupling is pretty universally considered a BAD thing, and it should not be a desirable trait. I would highly recommend that you work towards separating your views from the logic that drives them, and utilize the WPF MVVM approach. In the long run, you will be MUCH happier for it, and your application will be more maintainable and future-proof. It shouldn't matter if the presentation platform is Surface, Vista, Windows 7, or any other WPF-capable device...separation of concerns is a KEY thing that you should really strive to meet.

jrista 2009-08-27 19:07:22

Separation of concerns is definitely something I'm striving for; are there any situations, though, where separation of business and view isn't the optimal approach? I guess my hesitation is mostly due to the fact that most of the sources I've read emphasize keeping the View as bare bones as possible (code- and XAML-wise), but many of the neat things our apps do have little to do with the Model of the data.

Dave M 2009-08-27 19:26:02

@Unknown: like I said in my answer, it's not about modeling the data. It's about modeling the *view*. Keeping the code-behind bare bones is beneficial for testing, designer/developer collaboration and ongoing maintenance. But that is more a side-effect of doing MVVM, and isn't so much an explicit goal (at least, not in my books).

Kent Boogaart 2009-08-27 19:42:50

I reread your answer and understand the difference now, thanks.

Dave M 2009-08-27 19:48:53

@Unknown: I think you are kind of missing the point. If you do a lot of neat things in your view...and given that your using surface, I am assuming it has to do with animation, transitions, touch-capable features, etc. That IS view-related stuff, and it should be part of the view or the code behind the view. The thing about MVC is that it aims to separate your view from core application behavior from data model. If you tightly integrate those three, then your in for a tough time. But fancy view-related glitter and gloss still belongs in the view...don't separate it out.

jrista 2009-08-27 19:49:27

ansaurus

tags:

views:

answers:

Which Design Pattern to use for MS Surface Apps (WPF)?

related questions