How to Organize MVVM Files in a C# Solution

cmvvmvisual studio

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?

Best Answer

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.

Related Solutions

C# – How to make creating viewmodels at runtime less painful

The issue of dependencies when initiating a new view model can be handled with IOC.

public class MyCustomViewModel{
  private readonly IShoppingCartWebService _cartService;

  private readonly ITimeService _timeService;

  public ProductDTO ProductDTO { get; set; }

  public ProductDetailsViewModel(IShoppingCartWebService cartService, ITimeService timeService){
    _cartService = cartService;
    _timeService = timeService;
  }
}

When setting up the container...

Container.Register<IShoppingCartWebService,ShoppingCartWebSerivce>().As.Singleton();
Container.Register<ITimeService,TimeService>().As.Singleton();
Container.Register<ProductDetailsViewModel>();

When you need your view model:

var viewmodel = Container.Resolve<ProductDetailsViewModel>();
viewmodel.ProductDTO = myProductDTO;

When utilizing a framework such as caliburn micro there is often some form of IOC container already present.

SomeCompositionView view = new SomeCompositionView();
ISomeCompositionViewModel viewModel = IoC.Get<ISomeCompositionViewModel>();
ViewModelBinder.Bind(viewModel, view, null);

MVVM Pattern – Best Design Approach to Manage an Application

Alberto, about one and a half years ago I was where you are now, and I've learned a lot about MVVM, WPF and Programming Meta Skills on the way.

For the time being, I will refrain from answering your questions specifically, and like to get a few words out that are of general interest/guidance, if you will.

MVVM is a design/architectural pattern that takes some time getting used to. There is no one right or correct way, MVVM is practiced in many different flavors with strictly no code-behind on the one side, and a more "integrated view model"-like approach (with a certain amount of code-behind allowed) on the other side. As with many things in IT, this topic also borders on personal liking.

Don't make the mistake I made by trying to push in patterns (or someone else's design liking) for patterns' sake. Recognize your specific problems, and try to solve them one at a time. See how other WPF/MVVM experts are solving and buildings things. By recognizing a problem and finding a way to solve it, you learn your MVVM/WPF skill by heart. Many small steps will get you in the right direction faster than any doggedly "I'm trying to get this 100% correct the first time" approach.

Now to your question:

I cannot see any problem with your approach so far. The only things I'd like to comment on are:

Instantiate your VMs via lazy loading, so that they consume memory/processing time only on-demand. Also, if you're allowing re-setting your view model objects (see your setters), please make sure that the container class implements INotifyPropertyChanged.

public ViewModelDG2 SecondViewModel { get { return _viewModelDG2 ?? (_viewModelDG2 = new ViewModelDG2()); } }
As for your "loose coupling" concern: That one is more about providing interfaces to your specific implementation (classes). If the view is created in a different assembly, it might make sense to operate via internal classes and public interfaces.

Resources I can warmly recommend to you:

Best!

Best Answer

Related Solutions

C# – How to make creating viewmodels at runtime less painful

MVVM Pattern – Best Design Approach to Manage an Application

Related Topic