0

Here is the context. The apps will:

  • consume existing (and standard) web services.
  • app is UI intensive (UI updated frequently and lot of data to display).
  • development team experience level is average.
  • development team has very few experiences in silverlight & WPF.
  • I want it simple, but I want to avoid a complete rewrite in the near future, so I must (try to) take a correct path from the beginning.

I know that using no pattern at all is the easiest and fastest way to go, and that implementing MTVT is the phantasm of all the .NET architects out there. But I don't have the budget ;)

I need a pragmatic solution, easy to implement, easy to understand, and that works.

When I browse the internet, MVVM Light is well positioned, but Microsoft is proposing its own implementation. Will it become standard like ASP.NET MVC?

Improve this question

2 Answers 2

Reset to default
3

Whichever implementation you choose, for Silverlight/WPF, MVVM is definitely the de-facto "standard" pattern. There's a lot of work been done in the Patterns & Practice department of Microsoft around some tools and scaffolding for making the project set-up a lot easier. As you mentioned, there's MVVM Light, and also Prism.

From experience in developing a WPF app at work, one of the most important things I found to get right about MVVM is communication between the ViewModels.

If you use the EventAggregator class from the Enterprise Library (or any other messaging bus), it will help keep your ViewModels much more decoupled and testable. Add to this a Dependency Injection container to automate providing service classes and the EventAggregator to each of the ViewModels, and you'll end up with a very maintainable and easy to use codebase :)

Improve this answer
2

We have implemented the start of an application using the MVVM pattern (we use Prism). There is a lot that is good in it, but the startup time is lengthy. I started with zero WPF and MVVM knowledge. Once you've done it for a while, it just feels natural. There are some aspects that feel poorly thought out (e.g.: popup dialogs, security). We wasted a lot of time on what was kinda suggested by the Prism team before going it our own way with popups. Our UI has a lot of complex business rules which would be a pain no matter how you code them.

If I had my time again, I would definietly go MVVM but I'm not so sure about Prism. I'm not too fussed about the longevity of Prism since we have the source code and, in the end, we could convert across to another framework. Thats the joy of MVVM - everything is nice and safely compatmentalised.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.