I've been reading and watching videos on MVVM and Silverlight.. I'm pretty new to Silverlight but not new to .NET. Interesting that I used MVVM in my WPF apps without knowing that it's MVVM. I was creating easily-bindable classes to serve as a layer between data and XAML :)

Project that we start will be done with Silverlight 5 and WCF on a back end.

Project will be rather large with several modules 50 or screens each, ideally I would like to load them on demand. MOST(not all) UI will be straight-forward data entry stuff.

I'm trying to see what should be our architecture and how will it benefit us in future.

I think I GOT IT as far as what MVVM and WHY. I also checked Caliburn Micro (and understood what it does). I see ReactiveUI and MVVMLight. To be honest I don't like external libraries/dependencies. Also, I don't really care about using naming conventions to satisfly external framework and perfectly OK with binding in XAML. Since we have good commands support and XAML debugging in SL5 - I don't think I need external framework.

So, I think having ViewModels and binding via XAML with minimal view-related code in code-behind will be perfectly fine with me.

Here is my dilemma:

  1. If I use RIA services. 80% of my UI will bind perfectly to RIA generated stuff with some converters of course. Will it be bad architecture to have everything bind directly and just some more complex views to use ModelView?
  2. Should I use RIA services?! I think YES. I'm all for generated code especially when it's plain data-entry stuff. Will it keep client code synced with server-side?
  3. From what I see - ModelView have to be manually coded. Am I correct? Again, for 80% of project that's probably going to be waste of effort.
  4. If I want to have multiple xap files that load on demand, should I use some kind of framework? I think keeping it in one file may get too big.


1 Answer 1


I built a MVVM (WPF) application for a client about a year ago. The app consisted of multiple modules, tens of screens with up t0 50 fields per screen. I used Prism for the MVVM framework for the screen/region management. I added another simple framework to handle multi-lingual support and built security myself.

I found it beneficial having Prism handling all of the screen region stuff. It was a chunk of work I did not have to worry about plus I could get working samples and on-line help when dealing with problems. In some areas were guidance was missing or light on (popup screens and field security) I went my own way. Prism handled all of my module discovery and screen handling capabilities. Silverlight will have a different set of concerns, such as network latency. These concerns would have been dealt with if you use an existing framework.

Some of my modules have web service back-ends, so had hand coded VM and Models. One had a Entity framework back-end, so the VM was hand coded and the Model was generated. We briefly looked at a RIA back-end it seemed well setup for a 5 minute demo, I'm not sure how well it would scale for a complex application with lots of business logic.

Long and short, if you are going down the full MVVM path, I'd suggest using a MVVM framework but be aware it may not cover everything you need. If you application really is that simple, direct binding to RIA could work but validate it against your most complex screen before you commit to it - this means checking security and validation as well as the simple stuff.

Your Answer

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

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