Project structure for MVVM in WPF
What I usualy have goes like this:
- Main Application (.exe) - Global Styles, etc
- Common Lib WPF - Base Classes and Helpers for WPF
- Common Lib General - Base Classes and Helpers for Models
- Infrastructure - Dependency Injection, Logging, etc
- Interfaces for VM
- Interfaces for M
- Several Libraries containing Views and corresponding ViewModels - Splitting here is possible as well
- Several Libraries containing Models
All dependencies are based on Interfaces only resolved via DI.
Friends, the solution I found for a problem similar to this was to create a separate project, the type WPF, I called Startup, only with App.xaml (and App.xaml.cs).
In it I refer to the project of the View and ViewModel. So the view has no dependence and ViewModel "sees" only the View and Business.
In App.xaml.cs declare and instantiate my MainWindow then load some basic properties of my app and navigate to page Login (I'm working with a Window and several pages browsing within them).
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.
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.