I am currently working on an LOB application which I am basing on the MVVM architecture. Going by the answers to the questions I'm asking, it seems like there are not that many people building large and/or complex applications in MVVM.

Hopefully, there is a number of you who have built such animals. If so, have you found that MVVM scales?

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

Follow-up to my own question: The project that I was working on was 90% complete when I left the company (contract expired). By the time I left, we had implemented 3 independent modules, the smallest with 10 screens and the biggest with about 50. The largest of the screens consisted of a dozen tabs with one tab having 50 odd fields. Some used Entity framework, some web service calls. For the most part, MVVM worked well and (IMHO) better than anything else would have. Issues were found in security (we had per field security) and inadequate guidance on popups (we used Prism).
–
daveJul 31 '11 at 20:27

4 Answers
4

I have worked on multiple large, enterprise-scale projects and MVVM was the KEY to keeping them scalable and maintianable. I can't imagine having separate design and development teams being able to work in true parallel without the workflow enabled by the pattern, nor would we have been able to have the team split between tiers, i.e. having someone code the WCF/service layer, another handle the view models, another work on persistence, etc, with unit tests to help with refactoring and even integration tests before other layers became available.

I didn't start with MVVM because it was a popular pattern, I selected it when I had to go to a massive Silverlight application and researched the best way to manage it.

Projects include a major social media networking tool for Microsoft called Looking Glass, the backend health monitoring system that ran the 2010 Vancouver Winter Olympics for Microsoft, a complex risk management SharePoint dashboard with Silverlight integration for PriceWaterhousecoopers, and the Blio reader (KNFB) that runs on both WPF and Silverlight. Those are just the ones I can talk about. Team sizes ranged from a few to dozens of developers and designers working simultaneously.

If people are having trouble scaling large projects with MVVM, or if it is slowing them down rather than speeding up delivery, they're simply doing it wrong.

I'd also say that if you are showing 100 fields on a single display, you might want to call in a design team because I don't know many humans who can process that much information at once. In databases with thousands of pieces of information, the beauty of Silverlight is mining and presenting that information in a way that the user is able to manage the information on screen in bite-sized chunks. Also, if you're manually loading those fields, again, you're just not taking advantage of the tools and patterns out there. On one project it took me 2 hours to build a generator that could spit out the base classes and then business logic was layered on top. A short investment up front for faster development on the back end.

Typical rule: if you're repeating the same thing hundreds of times, go find a tool or build one to automate it.

Thanks for the feedback. I have no doubt that it is one of the best ways of going, it just helps me justify this to management if I can say others have also done it on a large scale. As for the 100 fields thing - luckily this is not a problem for me on this project but I have seen it on others. Some application domains I've worked in, such as superannuation and share registry, capture massive amounts of information.
–
daveJan 19 '11 at 20:08

I agree that MVVM has been key to the success of several enterprise-scale applications I have worked on. The consistent structure, testability, etc. make working in a team environment much easier. There is a pretty good learning curve getting it right, especially since there are as many interpretations of the pattern as articles, but once you get it, the benefits will be obvious.

Could you wait 8 months for my book to come out, I'll explain it all there ;)

There is nothing about MVVM itself that prevents scaling. There's a lot about it that enables scaling. Not just in terms of app performance but also in terms of how much functionality can be understood and navigated by developers because of how explicitly separating concerns simplifies the logic of the application.

On paper, there is nothing to prevent mvvm from scaling. I've just got a feeling, possibly invalid, that few have actually built a large system in mvvm. View models are great, but if I've got 100 fields in my model, then I've got to have 100 properties in my view model. I then may need to add security. Since WPF does not allow binding onto a function, that means that could be two more properties (visibility and enabled) per field. Now we're up to 300 properties. This is not necessarily mvvm's fault - wpf has a lot to do with it too. Hence the question: has anyone really done this?
–
daveJan 19 '11 at 3:56

I've built very large scale systems with WPF (using MVVM) and a number of other technologies. Never in my life have I come across a system that needed to display a single entity with 100+ fields. Well I have, but that was in a dynamic Entity Attribute Value system and we built the viewmodel and view dynamically for that.
–
Mike BrownJan 19 '11 at 4:12

2

I once worked on a system (not mvvm and not my fault) with 350 fields on a screen spread over 27 tabs. Like I said, not my fault.
–
daveJan 19 '11 at 4:15