2

I'm starting a new project that will be developed in WPF as a desktop application. I have spent days researching development patterns. It seems that MVVM is the way to go, as this will be an enterprise application. My concern is that all of the information I am finding is dated 2009. Can anyone tell me if this information is still valid and if I am looking in the right direction?

Thank You In Advance.

  • The first Google result for `wpf mvvm` I get was last updated in February 2012. Yes, of course the MVVM design pattern is still valid. – madd0 Jun 13 '12 at 13:22
  • 1
    Don't want to make any personal advertising but i can assure you that MVVM and WPF is pretty capable for handling even big projects quite nicely. But one advice, there is not "the MVVM" paradigm i'm pretty sure everyone uses it a bit differently and more importantly should do it. If something in the "original" mvvm doesn't suit you, change it, but keep it consistent throughout your project. – dowhilefor Jun 13 '12 at 13:44

5 Answers5

4

Yes, MVVM is definitely still the way to go for any WPF development

The design pattern is perfectly suited to the nature of WPF's framework and binding system. I actually have a simple MVVM example posted on my blog if you're interested.

Rachel
  • 130,264
  • 66
  • 304
  • 490
  • Totally agree, I find myself using MVVM even for small personal projects, it's just become the way I think when writing WPF now. – Andy Jun 13 '12 at 13:25
0

Caliburn micro is a MVVM library recently upodated: http://caliburnmicro.codeplex.com/ Anyway the MVVM concepts dis not change since 2009, and yes I can vote is the way to go.

Felice Pollano
  • 32,832
  • 9
  • 75
  • 115
0

Yes your direction is right.

Even if some MVVM information is from 2009, there are WPF MVVM based frameworks that are regularly updated such as Caliburn micro and MVVMLight

I suggest you to spend some time with one of them because they can really help write clean code. I personally like Caliburn Micro.

Klaus78
  • 11,648
  • 5
  • 32
  • 28
0

Yes, MVVM is the way to go.

I have used MVVM in most of my applications; When I joined a new company I saw team struggling with the WPF application they were working on from past 1 year, perfromance, maintainabilty, reusability were some major issues; when I looked at the code the only thing came to my mind for solving all the problems was - MVVM.

We refactored the code implementing MVVM properly and were able to get rid of 20-30% code, reuse a lot of code and improve performance to acceptable level.

MVVM(when strictly followed) not only helps you to use WPF features correctly but kind of forces you to look into the solution in WPF way(instead of solving them without using WPF features or using WinForms ways), so it becomes more important and helpful for new teams.

Here are some SO questions which I would suggest you to go through -

What is your experience with abandoning MVVM for UserControl-based WPF architecture?

Starting WPF MVVM. Use a framework?

Custom MVVM implementation Vs. PRISM

Which WPF control suite is best suited to MVVM?

Community
  • 1
  • 1
akjoshi
  • 15,374
  • 13
  • 103
  • 121
0

Generally speaking, any of GUI archtitecture patterns can be implemented and used with WPF, Martin Fowler explains in details most popular of them in his blog.

MVVM as the latest stage of Presentation Model pattern is a famous for WPF because it provides us out of the box syncronization state mechanism like binding, simple view model on a view mapping like data template etc. and there are a lot of examples how to build MVVM with WPF.

But it depends of the particular project and some times you can easily build your WPF solution following MVP pattern, f.i. if you use third party WPF controls which are not mvvm-friendly (they uses regular properties instead of dependency properties, so you can't use WPF bindings and contains a lot of methods, that reduces ability to use control declaratively from XAML), you should spend aditional effort to adopt them to mvvm pattern.

Vladimir Dorokhov
  • 3,784
  • 2
  • 23
  • 26