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?
2
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.
4
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.
Edit (10 years later!):
One could say that this is an application of the Vertical Slice Architecture in the frontend.
1
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.
1
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.