Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 3 down vote favorite
1

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?

share|improve this 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). – dave Jul 31 '11 at 20:27

closed as not constructive by Walter, gnat, Thomas Owens♦ Oct 19 '12 at 13:05

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 specific 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, see the FAQ for guidance.

4 Answers

up vote 7 down vote accepted

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.

share|improve this answer
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. – dave Jan 19 '11 at 20:08
up vote 0 down vote

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.

share|improve this answer
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? – dave Jan 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 Brown Jan 19 '11 at 4:12
1  
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. – dave Jan 19 '11 at 4:15
up vote 0 down vote

I’m currently working on an enterprise application using MVVM pattern with DDD. This is my personal experience:

  • Debugging is hard during decoupling and data binding
  • If there is any evil in data binding then you have it here
  • People who work in such project must be familiar with architecture. It’s easy to code stuff - at wrong place. Otherwise the patterns become evil.
  • It’s is very scalable
  • Validation is easy as long as there are strong business objects
  • I haven’t found any good exception handling in MVVM with DDD
share|improve this answer
up vote 0 down vote

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.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.