Project structure for MVVM in WPF

Question

What is the project structure you end up with when using MVVM in WPF?

From the tutorials I saw now, they usually have folders: Model, ViewModel and View.

In Model you put classes like Person for example that capture data and logic.

In ViewModel you instantiate classes defined in Model. The View contains .xaml files.

Edit: I edit my original post to send an example project structure. I have question related to this. How do I organize these: App.config App.xaml MainWindow.xaml

Should I leave them outside like they are now or should I put them in some folder?

Answer 1

You have described the usual or common folder layout. From experience, I prefer to add a separate folder (or project in large applications) for the model data type, such as the typical Person class that you mentioned. The reason that I do this is because this often becomes one of the biggest projects. I also split it into the following sub folders:

DataTypes     Collections     Enums     Interfaces 

I also have separate folders (or projects in large applications) for the application Converter classes, extension method classes, utility (or service) classes. Finally, I have test projects that pretty much match the application folder structure. In total, this is roughly what my folders look like:

Solution      Third Party Libraries <<< (Solution Folder)      StartUp Project         Images         Resources      Converters      DataTypes         Collections         Enums         Interfaces <<< (For Data Type classes)      Extensions      Models         Data Controllers         Data Providers         Interfaces <<< (For swapping Model classes out in test projects)      Utilities (Or Services)         Interfaces <<< (For swapping Utilities classes out in test projects)      View Models         Commands      Views         Attached Properties         Controls 

UPDATE >>>

Projects, like folders, just provide levels of separation. They also help me to map out my application namespaces. For example, code classes in the Collections folder/project will be in the ApplicationName.DataTypes.Collections namespace. Classes in the Data Providers folder/project will have the ApplicationName.Models.DataProviders namespace.

Furthermore, in large applications, my project names come from their location in this hierarchy... for example, my DataTypes project is actually called ApplicationName.DataTypes and my Models project is called ApplicationName.Models. The Collections and DataProviders parts are folders, along with all of the items past the second level, eg. Enums, Images, Commands, etc.

Answer 2

Most people use the "standard" structure you mentioned:

• Model/
  • CarModel.cs
  • DriverModel.cs
• ViewModel/
  • CarViewModel.cs
  • DriverViewModel.cs
• View/
  • CarView.xaml
  • DriverView.xaml

I think the reason why it's popular is because some people will argue that you should be able to put Models, ViewModels and Views in different assemblies.

Also with this structure, you can easily add folders for other WPF stuffs: Converters/, Resources/, etc.

Within my team, we use this structure but we pluralize the names (so Models/ViewModels/Views).

However, most of the time, model classes are defined in other assemblies/namespace; in that case, we don't even have a Models/ folder.

For large projects, we add subfolders into the Models/, ViewModels/ and Views/

For the sake of completeness, it's worth mentioning that you may find a few people using a "feature driven" structure:

• Car/
  • CarModel.cs
  • CarViewModel.cs
  • CarView.xaml
• Driver/
  • DriverModel.cs
  • DriverViewModel.cs
  • DriverView.xaml

But it's very uncommon.