MVVM Framework: Performance

Question

I'm currently searching what will be the Framework that we will use for our nexts applications. Currently we have applications running with winform and we plan to switch slowly to WPF(with new application, and then refactoring the GUI). We are a team of 9 people working this solution.

We have a big solution(currently, 300+ VS projects, ~1'500'000 line of code), so when choosing a framework, we are looking for something which will promote a clean code, a good infrastructure, but also a framework that will not slow(too much) the application.

Currently, I'm mainly interessted in Prism(which seems to be a little bit complex to fully understand) and Caliburn.Micro.

The Caliburn.Micro seems easier to use, but I'm a little worried that all those convention oriented stuff means that a lot of things will be done using Reflection on runtime.

Am I correct? Or is this something done at the compilation ?

Also I'm not sure I should consider MVVM Light, since it lacks of documentation/targeted application sizes.

Answer 1

First of all, Prism is not a MVVM framework. There is Prism.MVVM and it is a very lightweight MVVM library and it's independent of Prism.

Second, this <ListBox x:Name="Products" /> automatically databound to viewmodel should not be a performance problem in Caliburn.Micro, because plain Binding in WPF uses refelection anyway. Not sure if Caliburn uses reflection internally as well, but even if it does, it's hardly noticable at runtime if you dont do it in iterative scenario, e.g. inside ItemsScontrol with 1000+ items. If you experience preformance issues, nothing prevents you from writing it the standard way. However, the added value of this is questionable. IMO it brings more problems than it solves

If I may give you my advice, don't use any MVVM framework. All you need is INotifyPropertyChanged implementation and DelegateCommand (ICommand implementation). In some special cases you may need EventAggregator. Now tell me, are those three classes worth a framework? No, the aren't. Why introduce a dependency to a third party library?

If you are going to start such a large solution, the investment to write your own base class library is negligible. You can always take the source code of a class or two from Prism and use them in your own library.

The problem with those framework is that developers tend to over-engineer simple scenarios, such as using EventAggregator where plain event or even direct reference is more suitable. Or take Prism as an example, they use regions and view injection where simple ItemsControl could be used.

After 6 years experience with WPF I became a big proponent of ViewModel-First approach. MVVM then becomes much simpler. But most frameworks work better with View-First approach.

So, my vote is to not use any MVVM framework. If you have to use one, choose Prism.MVVM. And look at the source codes, they are well written.

Answer 2

I have used CM for a few years, start back when it was 1.1. I came over from PRISM. While I agree for some of the comments and points of view from other posters, you truly only option at this stage is to get the library/framework (which ever you choose to play with), wire it up and run with it a little bit in your off time from major projects. Implementing it on your "paid time" might be less than beneficial since you will undoubtedly have questions while "experimenting".

Experiment first then make your decision. Want separation of concerns? Want rapid development? Want to be able to drop a control on workspace name it and it will just work (assuming it has a built-in convention, or create your own convention for a 3rd party control), wire some viewmodel code up to a property or method that you named the control, then give Caliburn.Micro a try. Don't want to use Caliburn's conventions then don't. Just about everything for CM is modularized in to core needs with Nuget installs.

There are many MVVM frameworks as well as libraries all have different niche areas some are multi-platform, some are laser targeted on 1 platform. You can only use what you try and at the end of the day if you find something you like using and it works for you and your team, then it (framework/library) is the one that should be targeted.

Example of why I left PRISM

On the View

<Button x:Name="ClickMe" />

In the ViewModel

public void ClickMe()
{
}

public string FirstName
{
  get{...}
  set
{
    _firstname = value;
    NotifyOfPropertyChange();
    NotifyOfPropertyChange( () => CanClickMe); )
}


public bool CanClickMe
{
    get { return !string.IsEmptyOrNull(_firstname); }
}