MVVM Light + Unity or Prism?

I am a little out-of-date in WPF right now and would be interested to hear peoples opinions on the latest version of Prism (which I used a couple of versions ago) vs an MVVM Light 开发者_开发知识库+ Unity approach (which I have never done - decent examples URLs would be good).

My project will be a large one comprising multiple modules written by several developers. There is also the funds to bring in a 3rd party control suite in order to set up a nice workspace using one of the fancy Docking/Workspace layout managers out there (and I know some play better with the Prism regions than others).

If you were starting a project from scratch right now, what would you go with and why? Details on specific recommended architecture patterns would be useful (e.g. auto discovery of module dlls? Injecting logging service?). Basically, any thoughts and advice would be good. I'd like to get a good discussion going. Perhaps there is another direction entirely that you would suggest going in? I'm very much in the research phase and would like as much input as possible.

I put this on here because I thought it would get less biased points of view than the Prism/MVVM Light forums but, if there is a more suitable place for this question, please point me in that direction.

If you need modularity, you'd want to look at Prism. Prism has some elements that can help you with MVVM (DelegateCommand and CompositeCommand, for example), but I think it's more complete with another MVVM framework.

There was a question a few days ago about how to model Prism. Check that out for a detailed explanation of how to consider Prism's functionality. High Level Modelling Advice for Prism MVVM

Unity is an implementation of an inversion of control container and it's definitely good, but Prism has the ability to use other containers. It has builtin support for MEF (which, in turn, is builtin to .NET 4.0), but it's not your only choice. Look at some of the samples included in Prism and decide what approach you like better. Unity is not complete on its own for UI compositing in my opinion. MEF might be a closer choice if you wanted to try to composite a UI with the MVVM Framework + IoC Framework approach.

MVVM Light is actually a complimentary framework to Prism. Other MVVM frameworks to consider:

• MVVM Foundation (very lightweight... good for small projects)
• Caliburn (very robust framework)
• Caliburn Micro (shares a name and an author from Caliburn, but it's akin to MVVM Light with some nice conventions)
• ReactiveUI (Formerly "ReactiveXAML". This is a bit of a brain melter, but if you learn Reactive Extensions for .NET (Rx), this framework is simply amazing... magical in my opinion.)

If I were going to start a new project: I would go with Prism and ReactiveUI.

Prism because you have to have modularity with large projects and I like the ability to remove and add large units of functionality to an app just by deleting or adding DLLs (and you don't have to implement the DLL sniffing feature like you would with just an IoC + MVVM approach). Easier to test, easier to debug, easier to develop separately. Nice all around.

ReactiveUI because with UI programming these days, most of your time is spent managing your time on the UI thread. Blocking is a no-no... users don't want to see a UI freeze; they want to see that animated GIF wait symbol spinning so they know they can work on something else while your data is loading. In addition, so much of the value applications provide these days is taking data from disparate systems and putting them together in the UI... not only will you need a good compositing system (Prism), but you will also need a good MVVM framework that treats asynchronous operations as its bread and butter... ReactiveUI is it.