I'm fairly new to the MVVM concept but like a lot of the flexibility it gives me so far. However, I'm struggling to find a good way to manage my code. I have several classes that are just sitting in a folder in my solution such as xxxView.cs, xxxViewModel.cs, yyyView.cs, yyyViewModel.cs, zzzView.cs, zzzViewModel.cs you get the idea. It has started to crowd my solution, making it harder to find the files I'm looking for. Is there some standard way to organize these files? Do I create a View and ViewModel folder to separate and clean up the solution or have people found a better way?


We use separate projects for

  • View
  • ViewModel
  • Model

And within those projects, we'll potentially add folders to provide additional structure.

The View project references ViewModel, and the ViewModel project references the Model.

Images often receive their own folder. So far, resource dictionaries, converters, and extended objects have been placed in the main project folder for the layer.

An alternative is to have "major application areas" as projects. Then you have either have V / VM / M folders within each area or you just place the related MVVM files in the area project folder.

I don't like this approach as much since I'll frequently have to work on multiple Views at a time so I end up navigating through a lot more project structure than I would like.

This approach kind of limits re-use when it comes to resource dictionaries or similar. The cross-referencing of projects can become difficult to maintain. However, creating a dedicated "common resource" project would be an approach to easing this problem.

  • We use the Application Areas structuring, so it seems, in my case, it would be best to create the View, ViewModel, and Model folders where appropriate. – lumberjack4 Jan 8 '13 at 23:12
  • I'm trying this structure but I came across an issue with page navigation. The view project contains the RootFrame which I need for navigation. The ViewModel project contains the logic to know when to navigate and to which View. How did you address this circular dependency? stackoverflow.com/questions/18415720/mvvm-solution-structure – n00b Aug 27 '13 at 4:16
  • @n00b - You already have a solid answer to your SO question. If there is something that isn't clear, or if you have an additional problem, then open a new question. If you're wanting my particular insight (why that would be, I don't know), I generally answer Programmers' questions and not SO questions so you would need to ask here. P.SE and SO have different focuses and you'll sometimes get differing answers as a result. Do not ask the exact same question though, you need to have a new issue to resolve or have your SO MVVM question migrated here. – GlenH7 Aug 27 '13 at 12:56
  • Isn't adding library references slower than directly using the .cs files? – Shishir Gupta Jul 17 '15 at 8:04

I have separated my solution in 8 projects:

  • Converters
  • Helpers
  • Models.Business
  • Models.DataContext
  • Models.Entities
  • Startup
  • ViewModels
  • Views

I had to create the Startup project only to house the App.xaml (and App.xaml.cs). Otherwise, I had circular reference problem.

I have been working with this format and is well practical and functional.

In the next step, I'll create test projects for each layer.

enter image description here

  • Why do you create a project for each one? Is it for ease of reuse in the future? For example, you could just refer to WpfProjects.Converters in another project? – Nicolas Jul 23 at 21:07

If you don't want separate projects, at least separate the different parts with project folders and namespaces.

I use a different pattern. I keep related view, viewmodel, and model in the same assembly, separated by namespace. Each new relationship creates a new assembly.


In one project we had more or less 60 "screens" with a lot of nesting and similar names.

Organizing it in Views, ViewModels and Controllers folders was quite difficult to work with, since the whole folder nested structure was replicated on all of the 3 main folders and going from the view model to its view and back was a pain.

I keep thinking that it would be a more comfortable-to-work organization by keeping together the files that belong to the same screen or functional area, like:

  • Section A
    • Section A 1
      • ISectionA1ViewModel.cs
      • SectionA1ViewModel.cs
      • SectionA1View.xaml
      • SectionA1View.xaml.cs
      • SectionA1Controller.cs
    • Section A 2
      • ISectionA1ViewModel.cs
      • SectionA2ViewModel.cs
      • SectionA2View.xaml
      • SectionA2View.xaml.cs
      • SectionA2Controller.cs
  • Section B
    • ISectionBViewModel.cs
    • SectionBViewModel.cs
    • SectionBView.xaml
    • SectionBView.xaml.cs
    • SectionBController.cs

Mainly because, at that project (and some others I worked with), those things are quite static. You will only perform small changes. And in the case of a huge refactor, it is easier to move from one file to the other, you can see them together in the Solution Explorer, which makes it very intuitive.

Also, If you have the Track items option activated in Visual Studio, it won't drive you crazy navigating up and down a lot all the time.

protected by gnat Jun 22 '16 at 16:47

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.