What do you do about ModelView files growing massive in a MVVM application?

I am writing a MVVM application and one of the screens is quite significant in size. The screen maintains and object that has multiple lists of other objects that also get editied within the context of the transaction.

I've broken the views up into multiple user controls. The model is broken up into the different class types. The problem is the ViewModel. Because it agregates information from multiple object types and does pass-through on so many properties, it is likely to be several thousand lines of code by the end. None of this code is complex, it just feels wrong.

Is this an una开发者_Go百科voidable consequence of the pattern?

Should I be looking at multiple ViewModels in this case? Possibly, one per model class.

How have people handled non-trivial examples in the real world (as opposed to yet another demo)?

thanks

BTW: WPF/Prism/C#/MVVM environment

---

I try to maintain a ViewModel for each View. This seems to work well for me, when it comes to communicating between the ViewModels ... there's a number of ways to handle this. Usually I use the Messenger class from Josh Smith's MVVM Foundation.

Bottom line though, there's really no reason for anyone ViewModel to get ridiculously large. There's always some way of architecting a project so that no one piece gets completely out of hand.

HTH

---

A bloated ViewModel is often a sign of a bloated View, maybe it can be divided into subviews?

Personally I often find that much of the code in the ViewModels is often boiler plate code to let the view know that some property has been updated (INotifyPropertyChanged). Take a look at Ayende's approach to solve that kind of bloating:

http://ayende.com/Blog/archive/2009/08/08/an-easier-way-to-manage-inotifypropertychanged.aspx

---

Why are your ViewModel files bloating up?

Like any other class you should be able to extract code out to smaller collaborators and then use delegation. Communication between VMs can be via Commands/events/method calls. A VM should treat another view or a higher-level VM as the same thing (another client).