MVVM separate assemblies Visual Studio: What should I choose as the project types?

Question

Many of the tutorials I see out there have the view/viewmodel/model folders.

If I were to separate each of these into separate assemblies using Visual Studio Projects, which project types would I pick for each piece?

I'm planning on using Prism 6 from NuGet and XAML.

Here is my initial feeling:

• Application: WPF Application
• Views: WPF User Control Library
• ViewModel: Class Library
• Model: Class Library

Or, should the views live within the higher level WPF Application?

Answer 1

Your initial segregation seems to be good. Your Application Shell and bootstrapper needs to be in an Application type project. Rest everything can be in a class library. If you keep Views in a separate library project, the advantage is you can replace it (better UI) without having to modify other projects.

It depends on your project complexity whether you actually require to split those classes into separate projects. Most of the times just a namespace is sufficient. If you are going for a modular design, each module may contain its own Views / View Models / Models, it facilitates a good level of abstraction.

Hope that helps.

Answer 2

I've worked extensively with many different MVVM projects, both as a contractor and a full-timer, and my opinion is that it depends on the nature of your development cycle. The example you've provided is reasonable if you have a team of programmers adhering strictly to TDD (say) along with a separate team of designers using Blend. However in most projects I've seen the programmers have been responsible for pretty much everything including writing the XAML by hand, and in these cases it's a lot easier to group solutions and folders by application systems rather than tiers. The majority of your time will likely be spent writing view and view model code, and when you edit one you'll almost always be making changes to the other so it'll save you a lot of hassle having them nearby, particularly as your application grows.

There is no one-size-fits all with this stuff, but I tend to do something roughly similar to this:

• MyApp (contains the application class and little else).
• MyApp.Controls (contains non-application-specific custom controls, usually isn't needed in a WPF app).
• MyApp.Domain (entities for DDD, ORM, business logic etc. many people would argue that this should be split further into a data layer.)
• MyApp.Localization (has to be in its own assembly for technical reasons due to namespacing)
• MyApp.Net (responsible for communication with other applications during full stack development ie servers, clients, managing websockets etc).
• MyApp.Settings (I usually need to add a large amount of user customization)
• MyApp.UnitTests (self-explanatory, particularly important for TDD).
• MyApp.WinUI (views and view models).

In addition to this there are various other projects for 3rd party libraries (MVVM dialogs, themes etc) and various console and/or windows utilities for database maintenance.

This is all specifically for Windows applications, the non-windows solutions also tend to get added to separate MVC and WCF components of the system, but that's another post! :)