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.

MVVM does not need to be fast as its operations tend not to iterate. Don't worry about it. Personally, I don't like the convention approach. — Gusdor, Apr 01 '15 at 07:01
You can try [MugenMvvmToolkit](https://github.com/MugenMvvmToolkit) is a cross-platform framework that also supports WinForms. It is very well suited for large projects. There are not a lot of documentation, but there are many examples. If you have any questions about the project I will gladly answer them. — Vyacheslav Volkov, Apr 05 '15 at 07:10
Can you provide few examples (from Caliburn.Micro docs maybe) where you think it will be slow? So far I've found only ViewModelLocator which uses reflection / convention and that is not something you should worry about — Liero, Apr 13 '16 at 11:01
@Liero By example: `` to bind to the "Product" Properties of the VM, this has to use reflection to get the property, right? — J4N, Apr 13 '16 at 11:04
Ok, I was not aware of this and I would never to do it, however it should not be performance issue. If it was, nobody is saying that you must use this convention. But this is why I dont like mvvm framework. You said that you expect that MVVM framework will force or guid you and your team to organize code the right way, but usually MVVM frameworks offers you too many ways, since they have to support every possible situation. By writing your own components like base classes for viewmodels, commands or services like navigation, you have much better control over your team. — Liero, Apr 13 '16 at 11:17
However it requires some experience with MVVM as well as some kind of talent to write good API, but that is why we call ourselves technical architects, isn't it? :) — Liero, Apr 13 '16 at 11:17

Liero · Answer 1 · 2016-04-13T11:26:15.103

11

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.

edited Apr 13 '16 at 11:26

answered Apr 01 '15 at 07:21

Liero

25,216
29
151
297

I've the impression that using a framework will guide us for the initial creation and give us a structure to respect, which is a good thing since it's our first "real" project with WPF. About the large project: The first application will be a small one, and since the goal is to convince the management to slowly migrate to WPF, if they see that it costs the double for the first application, I'm not sure they will be very happy. When you say ViewModel first, you still mean "after the model/business stuff" ? – J4N Apr 01 '15 at 07:32
it would be wise to start with small indipendent app. In that case use Prism.MVVM as a "Pattern and Practices library". It will guide you, thats true. avoid using prism, it will guide you wrong way. – Liero Apr 01 '15 at 07:37
By viewmodel-first I meant more view and viewmodel lifecycle than development method. see this for example: http://stackoverflow.com/a/28916120/475727 It basically says, that first you instantiace viewmodel and then based on naming convetion you instntiaces view. thats all. – Liero Apr 01 '15 at 07:39
Ok I see, Didn't think it was also used for the navigation. Caliburn takes this approach, right? But with this kind of approach, if we create a new view for a view model, we can't have both in parallels and then switch to the new one, right? – J4N Apr 01 '15 at 07:44
it's true only for pages. Byt having just one view per viewmodel and vice versa is recommended practice: http://practicalmvvm.com/Manifesto/ It just make things simpler. And you can still use inheritance to have similar viewmodels and achieve maximal codereuse – Liero Apr 01 '15 at 07:52
Yeah I agree, we only do this temporarily until we have it fully implemented. but at the end, it's not very often that we do this – J4N Apr 01 '15 at 07:55
"If you are going to start such a large solution, the investment to write your own base class library is negligible" - sorry to say this but there is negligible percentage of truth in this statement – too Feb 02 '17 at 13:50

score 1 · Answer 2 · edited Feb 20 '17 at 13:21

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); }
}

I appreciate this feedback. What make you go fro CM after PRISM? — J4N, Apr 02 '15 at 05:47
updated to show small snippet of why I left PRISM, this would require 2 times the code above what is done, since you would need to create a RelayCommand with execute & canexecute delegates and then pass in the necessary other items then on the viewside you would need to set the IsEnabled and the Command properties — mvermef, Apr 03 '15 at 06:54

score 0 · Answer 3 · edited May 23 '17 at 12:25

0

Most WPF performance problems are not caused by the MVVM framework but how you implement your WPF application (e.g. are you using virtualized lists?). I think you should select your MVVM framework depending on your function needs (are all functionalities available, e.g. a command implementation, view model base class).

It is more important to define conventions and rules for implementing your MVVM/WPF and select the MVVM framework based on these rules. Some conventions and rules can be found in my article about recommendations and best practices for implementing MVVM and XAML/.NET applications.

There are lots of resources about choosing the right MVVM framework, for example:

edited May 23 '17 at 12:25

Community

1
1

answered Apr 01 '15 at 07:27

Rico Suter

11,548
6
67
93

I know that this is not the most important cause of performance leaks, but still, it counts for us in the balance of which framework we use. My question is only about performance, exactly because all those other resources(that I've already read) doesn't talk at all about this. – J4N Apr 01 '15 at 07:37
To be on the safe side, you should choose a library (e.g. MVVM Light) over a framework (Caliburn) as a library is less obtrusive and when there are specific performance problems in some area of your application you can still write your own code and not use the library for this area... – Rico Suter Apr 01 '15 at 07:41
I used MVVM light, and I loved it, the issue that I'm having, is that I cannot find any documentation, book, samples, which shows all the features I can use and how to use it. – J4N Apr 01 '15 at 07:45

MVVM Framework: Performance

3 Answers3