CODEWITHSUNDEEP
wpfmvvm
Adrian
Adrian

Reputation: 769

View and ViewModel getting too large

While adding extra functionality to the main view I have in my application, I've realized that the amount of code will soon become a problem (currently around 600 lines of code in my viewmodel and I still have plenty to add).

I've been looking around for articles on how to split/design your view into smaller components, but I haven't found a satisfying solution. One person suggested using child viewmodels but that presented with other problems (dependency between the viewmodels).

I've thought of using user controls, but there is nothing on the View that I use on other Views so it kind of defeats the purpose of user controls.

What is a correct approach in this situation?

Thanks, Adrian

Upvotes: 10

Views: 4787

Answers (4)

devdigital
devdigital

Reputation: 34359

If you want to split a view into component parts, then you need to do view composition. If you are building an MVVM app, then you should really be using an MVVM framework. Something like Caliburn.Micro makes view composition incredibly easy.

There doesn't necessarily have to be dependencies between the view models, they should only know about what they need in order to produce their view. This could be a subset of the business object that the parent view model contains. As the parent view model will have references to all of the child view models, it can pass the relevant parts of the business object to them at the point of their construction.

Upvotes: 3

Edmond De Savornin Lohman
Edmond De Savornin Lohman

Reputation: 31

Splitting up is not ideal.

It looks as if the Caliburn toolkit focuses on events, whereas my application largely relies on ICommand implementations.

To me, the first encounter with Caliburn.Micro has been unsatisfactory. The setup appeared to be tailored to VS2010 - which sounded promissing to me - because I do have VS2010 pro. But I got lost in the setup's of Silverlight. Compared to toolkits like Prism it lacks the ease of an start. It just takes to much time to switch now. I use my own MVVM paradigm, it is less abstract than the Caliburn, it integrates multilanguage support everywhere, and it just faces one acceptable problem of some sources getting too big because of the nature of the Binding/DataContext paradigm. For this problem I accept that "partial class" is a solution - even though I know there is a more elegant solution available.

In the heat of my work, I cannot change to another toolkit.

So I gently wait for Microsoft to allow for more flexibility around that Binding/DataContext paradigm.

It may be the case that Caliburn shows more intelligence allocating a viewmodel to some item. Does it ? (I think it does.)

What might be another option is to define a custom (xaml useable) object that triggers a custom allocator which control is to be allocated to which viewmodel. How about that ?

Upvotes: 0

Meirion Hughes
Meirion Hughes

Reputation: 26428

I would agree with using Caliburn Micro.

However, to play devil's advocate you could split out your ViewModel File into separate files (same class name) and use the partial keyword before the class keyword. Its generally tidier and one step-away (non-breaking precursor) from breaking-up into separate classes.

Upvotes: 3

Klaus78
Klaus78

Reputation: 11906

I also agree Caliburn.Micro is a good solution for splitting your application in smaller components.

In Caliburn.Micro the communication between viewmodels is based on the Event aggregator pattern.

This makes a loose coupling between viewmodels

Upvotes: 1

Related Questions