This project is read-only.



Make a copy of the entire SolidMvvm folder that contains the README.txt file, rename it and the Visual Studio project in it to the name of your application. Rename the namespaces to match your company’s information. This is not a framework—it is intended to be copy/pasted and then modified.


Most other MVVM frameworks encourage top-down implementation. SolidMvvm promotes a bottom-up approach.

In a nutshell, top-down implementation means starting with the high-level objects and implementing your way down. Another word for top-down implementation is hard-coded implementation. Hard coded means that you implement the current business requirements, and when the requirements change, you rework it for the new requirements.

Bottom-up implementation means starting with low-level objects and working your way toward higher-level objects until they eventually coalesce to fulfill the business requirements.

I use both top-down and bottom-up approaches at the same time, though I always favor bottom-up for most of the implementation.

An analysis of the different approaches can be seen here:

A dialog of pros and cons can be found here:

If you have studied the S.O.L.I.D. principles (see, then you are probably interested in a bottom-up approach.

In a SOLID MVVM for WPF architecture, the view/view-model pairs are typically either top-down or bottom-up, but not both at the same time. The more bottom-up view/view-model pairs you create, the more self-contained building blocks you have, and thus the more resilient you are to unforeseen changes in business requirements.


- rely on any MVVM frameworks. Most MVVM frameworks support primarily top-down development, not primarily S.O.L.I.D. principles.

- rely on any inversion-of-control (IoC) containers. There are absolutely no global (public static) variables in the entire solution.

- use WPF commands. Views instead call view-model methods with the CallMethodAction.


- View model constructors take parameters. All of the models that the view model relies on are provided to it through the constructor, methods, and properties. Because of this, the views do not create the view models. View models are created independently of the view and they are joined by one of two simple mechanisms. See the documentation for details. [???need to provide a link here]

- The ViewModels project has no reference to the Models project, only to the Interfaces project. This forces interfaces to be used in place of hard-coded models to provide a layer of indirection (decoupling). A simple factory is used to create concrete models to provide the interfaces. The factory itself is also decoupled with an interface and can be swapped out for unit testing.

- All view/view-model pairs are self-contained. They do not reference any global (public static) variables. This keeps the code flow easy to follow because model information flows only through parameters, methods, and properties, never through reaching for global (public static) variables.


- Add theming support by default.

- Add a built-in way of saving settings for all view models (and other business classes).

- Add view/view models that show how to pop open dialog boxes, contain other view/view model pairs, or provide snap-in points.

THANKS TO for the App.ico and the blueprint picture on this page.



For any questions, or to provide feedback, please post to

Last edited Nov 18, 2013 at 5:01 PM by barnarddale, version 7