View and view Model too large

Question

When adding additional functions to the main view that I have in my application, I realized that the amount of code will become a problem in the near future (currently there are about 600 lines of code in my view model, and I still have to add it).

I was looking for articles on how to split / create my view into smaller components, but I did not find a satisfactory solution. One person suggested using child view models, but with other problems (dependency between view modes).

I was thinking about using custom controls, but there is nothing in the view that I use for other views, so it partly hits the purpose of the user controls.

What is the right approach in this situation?

Thanks Adrian

Answer 1

If you want to split a view into its constituent parts, you need to compose the view. If you are creating an MVVM application, then you really should use the MVVM framework . Something like Caliburn.Micro makes browsing a song easier.

There does not have to be dependencies between presentation models; they only need to know what they need to create their presentation. This may be a subset of the business object that contains the parent view model. Since the parent view model will have links to all models of the child view, it can transfer the corresponding parts of the business object to them at the time of their construction.

Answer 2

I also agree with Caliburn.Micro is a good solution to split your application into smaller components.

In Caliburn.Micro, the relationship between view modes is based on the Event aggregator pattern.

This makes a free connection between viewing modes.

Answer 3

I agree with the use of Caliburn Micro.

However, to play the devil’s advocate, you can split your ViewModel into separate files (same class name) and use the partial keyword before the class keyword. Its generally more neat and disposable (inextricable predecessor) from decomposition into separate classes.

Answer 4

Separation is not perfect.

Caliburn toolkit seems to focus on events, while my application is heavily dependent on ICommand implementation.

For me, the first meeting with Caliburn.Micro was unsatisfactory. The setup seems to have been adapted to VS2010 - it sounded like a promise to me - because I have VS2010 pro. But I'm lost in setting up Silverlight. Compared to tools like Prism, it lacks the ease of starting. Now it takes a lot of time to switch. I use my own MVVM paradigm, it is less abstract than Caliburn, it integrates multilingual support everywhere, and it faces one acceptable problem when some sources become too large due to the nature of the Binding / DataContext paradigm. For this problem, I accept that a “partial class” is a solution, although I know that there is a more elegant solution.

In the midst of my work, I can’t switch to another toolkit.

So, I gently wait for Microsoft to provide more flexibility around this Binding / DataContext paradigm.

It may be that Caliburn shows more intelligence by highlighting the viewmodel for some element. Does it have? (I think yes.)

What could be another option - to define a user (xaml-used) object that launches the user distributor, which control should be assigned for any model viewmodel. How about this?