How do you organize your Models/Views/ViewModels in WPF

Question

This has been a constant irritation of mine, so I thought I would ask for suggestions. How do you organize your Models/Views/ViewModels in WPF (Solution Explorer)? I can never seem to find a solution that I'm happy with so I'm wondering if there is someone out there that has.

Answer 1

Aside from the fact that your Models should be in their own assembly (project). I tend to put Related Views and ViewModels together in a single Folder, rather than having a folder called "Views" and Another one called "ViewModels"

Say, for example:

Project MyApp.Model
    |---> Models


Project MyApp.Client
    |--> Orders
    |      |--> OrderCRUDView
    |      |--> OrderCRUDViewModel
    |      |--> OrderListView
    |      |--> OrderListViewModel
    |--> Accounts
           |--> AccountCRUDView
           |--> AccountCRUDViewModel
           |--> AccountListView
           |--> AccountListViewModel
    ...etc

Answer 2

How do you organize your Models/Views/ViewModels in WPF (Solution Explorer)?

I typically have the Model in a separate project. One of the main goals in MVVM is to keep the model isolated from the View and ViewModel entirely.

The View and ViewModel depends - My personal organization style differs based on project scope.

For very small projects, I often have the View and ViewModel for each "view" side by side.

For larger projects, I will separate these into their own namespaces (and folders), or even into separate projects. Having the ViewModel in a separate project from the View is nice in that it can enforce that your ViewModel does not refer to View elements, as you can leave the required references out of that project entirely.

Answer 3

In a larger application you might wanna throw stuff into separate assemblies but I think this would work just as well.

Project MyApp
    |--> Views
    |      |--> AccountsView
    |      |--> OrderView
    |--> Sources
           |--> CustomerData
                  |--> Data
                  |     |--> DataAccess.cs    <-- Provides database search helper methods that return ObservableCollections of "Model" data types for use in the ViewModels.
                  |--> Models
                  |     |--> Account.cs
                  |     |--> Order.cs
                  |--> ViewModels    <-- Having more then one viewmodel for the same data is possible, e.g. Master-Detail scenarios.
                        |--> AccountsViewModel.cs
                        |--> OrderViewModel.cs

Answer 4

I separated them into different projects then broke it down from there. Basically M project, VM project, and then the View as the main project. Though eventually V & VM became more tightly coupled.

Answer 5

I'm a 'Solution Folder' person...

I keep a given V and VM together in the same assembly and put all V/VM assemblies in a 'Solution Folder' created by Visual Studio.

Models and Utility classes are isolated by assembly and also pushed into a 'Solution Folder'.

And of course, there's a Solution Folder called 'Infrastructure' that contains the magic strings and so on...

Solution Folders are a logical designation. They do not create physical folders on your drive.

Answer 6

This has been my starting basic setup for non trivial projects for almost a decade and it's simplicity has served me well. The terrible practice of keeping views and view models in the same project seems to be is a prism thing but the MVVM community shot that anti-pattern down a decade ago.

Client Tier:

ProjectName.Client.csproj
    --Assets
    --Images
    --Brushes
    --DataTemplates
    --Styles
    --Controls
    --Helpers
    --Views
ProjectName.Client.ViewModel.csproj
    --ModelViews
    --ViewModels
    --Helpers

Server Tier:

ProjectName.Server.Services.csproj
ProjectName.Data.csproj
ProjectName.Model.csproj

The view model layer doesn't reference a "Model" project as that exists in the server tier and is exposed to the view model via a proxy of the data service reference.