Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
2  
Microsoft has a reference implementation here that you can study. –  Robert Harvey Jan 8 '13 at 21:47
    
@RobertHarvey Thanks! That will work well for our solution structure. –  lumberjack4 Jan 8 '13 at 23:09

3 Answers 3

up vote 2 down vote accepted

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.

share|improve this answer
    
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

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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