Is it good practice to make a Model static in WPF (MVVM)?

Question

Let's say some, not all, models in an application are static and are defined as members of a BaseViewModel such that multiple ViewModels (and by extension, Views) can access the exact same data by hitting that which they have inherited. Here is a very basic layout where two derived classes can access the same Model:

public class EmployeeModel
{
    public string Name;
    public int Id;
}

public class BaseViewModel
{
    private static EmployeeModel employeeModel = new Employee Model();
    public EmployeeModel EModel 
    { 
        get { return employeeModel; } 
        set { employeeModel = value; } 
    }

    public BaseViewModel() {}
}

public class EmployeeViewModel : BaseViewModel
{
    public EmployeeViewModel() 
    {
        base.Emodel.Name = "";
    }
}

public class HomeViewModel : BaseViewModel
{
    public EmployeeViewModel()
    {
        base.Emodel.Name = "";
    }
}

In the end, it got the job done as the same data is now showing in multiple views without issue. However, that does not mean there isn't a more appropriate way of which I am unaware. As I am new to WPF, I feel compelled to ask, "is making a model static good practice for the MVVM pattern?" In addition, can this implementation be optimized, and if so, how?

Answer 1

This is not a bad practice, would say. So in your case when using model static , makes your program behave as expected, this is a good practice.

Alternative could be to not declare this model static , but declare some static model holder, which returns exactly the same instance on request, so on different view, like now, you will see the same model presented in different way.

hope this helps.

Answer 2

I would say it isn't good practice. You should favour composition over inheritance . If you wish all of you views to share a common piece of UI which shows some employee information (presumably the currently logged in employee), then you're talking about view composition.

If you're using MVVM then you should use an MVVM framework . Something like Caliburn.Micro makes view composition incredibly easy. In this case, you would have for example a HeaderViewModel with a corresponding HeaderView , and that HeaderViewModel would take the employee model as a dependency (for example injected into the constructor).

The other view models would then take the HeaderViewModel (or factory) as a dependency through their constructors.

If you're referring to displaying the same model in different ways, then just pass the model as a dependency via the constructor to the view model (assuming the dependency is required), and have the view model either expose the model directly (violating the LoD) or delegate calls to the model (violating the DRY principle).