Wpf Prism application architechture with the MVVM pattern

Question

I'm currently introducing Prism to a new Wpf application, and am using the MVVM pattern. My initial approach of structuring the Wpf application was to add one project to hold the model classes, one to hold the viewmodel classes, etc. These might be split at a later time to avoid having different logical components in the same project. However, this strikes me as a bad structure when using Prism (and parhaps in general..).

In Prism you want to structure things into different logical modules - where anything related to the same things would be placed in the same module. So this tells me I should put all related to a logical part of my application into a module for this part. This might hold some different views for this component, the related view model, and the necessary model classes. Using this approach I would however get the model scattered around my solution. As the model will be tied to a database this strikes me as a possibly bad approach after all. I am using NHibernate, so the database won't really be that "visual" though.

So I see three different structures. Are any of these typically desired? Or is there a different way I should structure my application?

1. Projects "Model", "ViewModel", and also one to hold UserControls. Etc..
2. One project pr logical part - including both related view, viewmodel and model for this part.
3. One project pr logical part - including view and viewmodel, but the model being defined in a separate project. Maybe even one project for all model classes if they have a logical relationship.

Any opinions are greatly appreciated!

Answer 1

Putting your Model in a separate project is fine. I'd say it's recommended it if it's big enough to really benefit from prism style architecture. The model is not confined to the vertical silo of the V and VM, but is a lower layer that sits below all of them.

Your Views and View Models make sense living close to each other. You might find reuse of views or of view models, but don't stress if you don't. That said, a view isn't always tied for ever and ever to a specific view model and vice versa. For example, I my have a view model that shows all sales and a view model that filters on the current quarter but I can rig both to the same view. On the flip side, I have a pie chart vs. a bar chart on the same view model. So splitting these is not as cut and dried. However, you may find larger chunks than just view/view model pairs. Sales vs customer management and such.