R – How verbose should names be for Model-View-ViewModel (MVVM) classes and instances

mvvmnamingnaming-conventionsverbosity

In general, I prefer to be verbose with .NET class and instance names, but some times (to quote Mike Woodhouse):

Over-verbosity tends to conceal syntax, and syntax is important.

The first place I felt like I really strayed into the over-verbosity regime is upon implementing the Model-View-ViewModel (MVVM) pattern in Silverlight and WPF apps.

For example, I start with an EnumerableRange model object:

public class EnumerableRange<T> : IEnumerable<T>
{ 
    public T Start{ get; set; }
    public T Stop{ get; set; }
    public long Count{ get; set; }
    ...
}

Then, I want to create a control that will allow me to surface this class for user input. Thus, I create a pair of view-related classes:

an EnumerableRangeControlView UserControl (in XAML), and
a POCO EnumerableRangeControlViewModel

Now, I use this pair in the parent View and ViewModel, respectively. With MVVM the view instance doesn't need a name, but my ViewModel instance is now named something like:

IndependentVariableEnumerableRangeControlViewModel.

Things are starting to get out of hand! What would you do?

Best Answer

I propose the following:

Drop the word "Control" from View/ViewModel classes and instance names altogether. "View" and "ViewModel" clearly state the class purposes.
(Optional) Consistently adopt a convention to post-fix ViewModel instances with "VM".

In the example above, the instance name

IndependentVariableEnumerableRangeControlViewModel

becomes a much more readable

IndependentVariableEnumberableRangeVM

Related Solutions

Python – the naming convention in Python for variable and function names

See Python PEP 8: Function and Variable Names:

Function names should be lowercase, with words separated by underscores as necessary to improve readability.

Variable names follow the same convention as function names.

mixedCase is allowed only in contexts where that's already the prevailing style (e.g. threading.py), to retain backwards compatibility.

R – How to connect the ModelView to the Model in this Silverlight MVVM example

The way I use a ViewModel is somewhat different. In my case it actually wraps the Model class passing most of the data on to the model. That way all standard business rules in the model still work the way they are supposed to right away. The ViewModel only exposes those properties actually needed for data binding or other UI purposes. Additionally the ViewModel might contain other properties/methods used for data binding.

So using your customer example: namespace TestMvvm345 { public class CustomerViewModel : INotifyPropertyChanged {

    private Customer _model;
    public Customer Model
    {
        get
        { return _model; }
        set
        {
            if (_model != null)
                Model.PropertyChanged -= Model_PropertyChanged;

            _model = value;

            if (_model != null)
                Model.PropertyChanged += Model_PropertyChanged;
        }
    }

    void Model_PropertyChanged(object sender, PropertyChangedEventArgs e)
    {
        RaisePropertyChanged(e.PropertyName);
        if (e.PropertyName == "FirstName" || e.PropertyName == "LastName")
            RaisePropertyChanged("FullName");
    }

    public string FirstName
    {
        get { return Model.FirstName; }
        set { Model.FirstName = value; }
    }

    public string LastName
    {
        get { return Model.LastName; }
        set { Model.LastName = value; }
    }

    public string FullName
    {
        get { return FirstName + " " + LastName; }
    }


    public static IList<CustomerViewModel> GetCustomers()
    {
        var result = new List<CustomerViewModel>();
        var customers = Customer.GetCustomers();
        foreach (var customer in customers)
        {
            result.Add(new CustomerViewModel() { Model = customer });
        }
        return result;
    }
    public event PropertyChangedEventHandler PropertyChanged;

    private void RaisePropertyChanged(string property)
    {
        if (PropertyChanged != null)
        {
            PropertyChanged(this, new PropertyChangedEventArgs(property));
        }
    }
}


public class Customer : INotifyPropertyChanged
{
    public int ID { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public int NumberOfContracts { get; set; }

    public static List<Customer> GetCustomers()
    {
        List<Customer> customers = new List<Customer>();
        customers = new List<Customer>();
        customers.Add(new Customer { FirstName = "Jim", LastName = "Smith", NumberOfContracts = 23 });
        customers.Add(new Customer { FirstName = "Jane", LastName = "Smith", NumberOfContracts = 22 });
        customers.Add(new Customer { FirstName = "John", LastName = "Tester", NumberOfContracts = 33 });
        customers.Add(new Customer { FirstName = "Robert", LastName = "Smith", NumberOfContracts = 2 });
        customers.Add(new Customer { FirstName = "Hank", LastName = "Jobs", NumberOfContracts = 5 });
        return customers;
    }

    #region INotifyPropertyChanged Members

    public event PropertyChangedEventHandler PropertyChanged;

    #endregion
}

}

Now in your UI you bind using the following code: customerHeaderView.DataContext = CustomerViewModel.GetCustomers();

The code in the ViewModel does become somewhat large but a lot can be put in a base class and all properties that go to the Model are exactly the same (think T4 template).

Best Answer

Related Solutions

Python – the naming convention in Python for variable and function names

R – How to connect the ModelView to the Model in this Silverlight MVVM example

Related Topic