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?

enter image description here

Is your question about "project structure" or about what is MVVM ? Bascially in the folders "Models" you put your models, in "ViewModels" your view models and in "Views" your views... — franssu, Sep 16 '13 at 10:41

Sheridan · Accepted Answer · 2013-09-17T14:11:24.033

79

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.

edited Sep 17 '13 at 14:11

answered Sep 16 '13 at 10:50

Sheridan

68,826
24
143
183

2

It is interesting that you put the Commands in View Models? How come? I see many people just leave Commands as separate folder from anything else. – user2381422 Sep 17 '13 at 10:37
4

Putting `Commands` into `ViewModels` just removes the need to add another reference into the `ViewModels` project. I used to have a separate project for `Commands`, but I soon realised that `ViewModels` was the only project that ever used them, so it seemed logical to move it in there. Also, I only have one class in that folder; it's a form of 'RelayCommand', so all my `Command` objects simply use `delegate`s and ordinary methods. *If* I had loads of actual `Command` classes in there, I *might* be tempted to give it its own project. – Sheridan Sep 17 '13 at 10:54
3

Hmm, all of these are separate projects? Aren't they folders? – user2381422 Sep 17 '13 at 13:40
2

They can be either... I use folders in a small application and projects in a large application. It just depends on how many classes are in each really. – Sheridan Sep 17 '13 at 13:41
@Sheridan Specifically in case of a single project having views and VMs, which is very complex and large, what are your thoughts about 'feature driven structure' (as mentioned by 'Benoit Blanchon' in his answer) rather than having separate Views and ViewModels folders? – akjoshi May 07 '15 at 14:59
Hi @akjoshi, if I have a big project, I'd prefer to use sub folders inside my ViewModels and Views folders, but I certainly wouldn't use that 'feature driven structure' because I use separate projects for these top level folders... you wouldn't want a separate project for each feature, especially if you have lots. But that's just me... if you like that 'feature driven structure', try it out and see what you think. – Sheridan May 08 '15 at 09:10
this is really weird to me. using this approach, if I open up your solution, I would have to expand 10000 levels of directories and read the names of endless types to even get the faintest idea what your application does. if you have a library application, why not group things by staff, inventory, sections, using entities like employee, book, author etc? why would you want to group stuff by implementation details? this link speaks about java, but it's points work for all languages http://www.javapractices.com/topic/TopicAction.do?Id=205 – sara Jan 08 '16 at 12:24
I think that you must have misunderstood something. This example shows no more levels of hierarchy than 2, so I have no idea where you got the 10000 figure from. All the same, this is just roughly how I organise my files in my projects. You are welcome to do the same or to organise your files differently, that's up to you. Personally, I find that this works very well for me... others may not. If you really have 'endless types' in your solution, then you can use sub directories inside the DataTypes project. Perhaps you should offer an alternative answer with your Java link? – Sheridan Jan 08 '16 at 12:55
How about EventArgs files (eg. `DataUpdatedEventArgs.cs`). Where do you put that type of files? – Sam Dec 01 '17 at 11:35
@Sam, I don't typically use events, preferring to use delegates instead, but if I were to use them, I'd keep them in a sub folder where they were needed, most likely in the `Views` project/folder, or maybe the `StartUp` project. – Sheridan Dec 01 '17 at 13:45
The custom data types of properties exposed by ViewModel to the View would go to DataTypes folder, yes? – ed22 May 11 '21 at 13:37

score 35 · Answer 2 · answered Sep 16 '13 at 11:02

35

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.

answered Sep 16 '13 at 11:02

Benoit Blanchon

13,364
4
73
81

1

Can you please give some feedback, I edited my original post? Specifically, what do you do with those three files, App.config App.xaml MainWindow.xaml? – user2381422 Sep 16 '13 at 11:22
3

`App.xaml` and `App.config` stay at the root of the project. `MainWindow.xaml` should go in `Views/` (and have a view-model) – Benoit Blanchon Sep 16 '13 at 11:25
What if I have a single window? I guess then I need a single xaml file in Views, one corresponding file in ViewModels, and also one file in Models. Correct? – user2381422 Sep 16 '13 at 11:50
Exactly, but it's very rare to have only one view. Are you sure you can't split your `MainWindow` into `UserControl`s (each one having its own view model) ? – Benoit Blanchon Sep 16 '13 at 11:54
7

The feature driven structure is quite common in complex applications, because they allow a better focus. However, I only ever saw views and view models there, never the models. They are in a separate assembly anyway. – Daniel Hilgarth Sep 16 '13 at 12:02
1

The only problem I see right now with the feature driven structure is that if you put for example the DriverModel in there, you may have to add a lot of references depending on where you need that model. If you have all your models sorted like that, you may have one reference per model, depending how many you are using. – El Mac Mar 25 '15 at 08:08
So the main argument for the layer-based layout is that "you should be able to put Models, ViewModels and Views in different assemblies". Wouldn't it be, in most cases, an assembly for models and another for viewmodels+views? Models can be used in a web-app for the same database; view and viewmodels will go togheter in the desktop application and rarely will be separated. That will allow for a feature-driven layout at least for viewmodels&views. That is: once we got the major benefit of layered-layout, we can still organize our app around feature obtaining also the benefits of feature-layout? – AgostinoX Jan 17 '20 at 09:01

score 4 · Answer 3 · answered Sep 16 '13 at 10:51

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.

score 4 · Answer 4 · answered Jun 21 '16 at 16:46

4

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).

answered Jun 21 '16 at 16:46

Rodolfo Gaspar

88
2
8

4

Hi Gaspar, would you mind posting some more screenshots of the other folders expanded? It will help us beginners in MVVM to see how seasoned developers structure their solution. Many thanks. – user2430797 Dec 10 '19 at 23:03

Project structure for MVVM in WPF

4 Answers4

Linked