I'm starting to design and develop a WPF application for my company and one of the first choices that I have to make is whether or not to use MVVM.

The main points to consider are:

  • The application is basically a VisualStudio-like editor, where designers will create projects and will define UIs by dragging and dropping UI elements on a canvas
  • I will be the only designer and developer of such application
  • The project could last many months (from 4 to more than 12, depending on the features they will choose to add during the development)
  • Last, but not the least, I have a very basic and "young" knowledge of the MVVM pattern and of its relative frameworks (I just developed a little test application with MVVM Light, including RelayCommands and ModelViewLocator).

What should I do? Is MVVM worth it or is it just an overkill for a solo project? Is there something newer that could be helpful also for the future (e.g. I read something about ReactiveUI, but I know nothing about how it works) or have I to continue with the good old MVC?

Thank you very much for your help!

  • 1
    Brutus, I think you find that this site is not the place for a question like this. I believe people view this as an off-topic question, hence the two down votes. This may be a better topic for a Microsoft forum. Just my two cents.
    – Wade73
    Dec 21, 2016 at 13:25
  • @Wade73 thank you very much for your comment, I really appreciate it! Probably you are right, and maybe I've also made the question confused. What I essentially wanted to ask is: is MVVM still a good option in 2017? Is MVVM good for a single-developer project or just an overkill?
    – Brutus
    Dec 21, 2016 at 13:31
  • MVVM is the correct choice for any WPF application. Are you confusing the pattern with frameworks?
    – Ewan
    Dec 21, 2016 at 21:49

1 Answer 1


I'm a big fan of MVVM. The simple reason is I can change my UI and change frameworks any time I want. This is great, but in order to achieve full decoupling that will benefit in longer term, you should also think about implementing Depedency Injection.

What I found annoying about using MVVM is communication between ViewModels. That's where additional frameworks really can help out. You should look into using Prism or Caliburn.Micro. They allow you to use EventAggregators, IoC containers, guards and many more. With that they make Dependency Injection and communication between ViewModels easy.

MVVM will definitely help you solve many problems, but not all frameworks support MVVM. This means that you should do a little research and find what frameworks you would like to implement in the future and see if they are easy to implement using MVVM.

At first MVVM may seem irritating, but if you will strictly follow its rules you'll have a very easy to test and improve application. You will definitely need to test your application and with decoupled UI and Dependency Injection it will be much much easier.

  • thanks a lot for your answer, I'll follow your suggestion! I thought to use MVVMLight, which should also help me out with the communication between ViewModels (there should be a Messenger class for that). What I found irritating about MVVMLight is the few documentation available, in particular the official one. I also got a look at Fody, but I think it's too much simple. So, talking about documentation/support and examples available, which Framework would you suggest to me?
    – Brutus
    Dec 21, 2016 at 13:50
  • I haven't used many of frameworks that are available. I mostly base my knowledge on Prism and Caliburn.Micro. Prism is a little bigger and so for a single person project I would suggest Caliburn.micro. In terms of documentation, most of important stuff is explained pretty good. There are also many answered questions at StackOverflow, that will help you. Most of them involve XAML which can be a pain in more complex cases.
    – FCin
    Dec 21, 2016 at 13:58
  • 1
    @FCin: Why do you believe dependency injection will make the application as described easier to develop? It sound to me like the kind of application where it would just add needless complexity.
    – JacquesB
    Dec 21, 2016 at 14:04
  • 1
    @JacquesB In order to communicate between ViewModels, and use MVVM frameworks` functionality you have to pass ViewModels via constructors and in application where many things must have knowledge about many other parts of the application it is better to have an easy way to share interfaces between ViewModels. Functionality such as EventAggregator's, WindowManager's can also be irritating to pass throughout this kind of application.
    – FCin
    Dec 21, 2016 at 14:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.