How do I resolve this terminological confusion when refactoring existing code to use the MVVM pattern?

Question

I'm struggling with a terminological conflict and can't figure out a good resolution. Maybe someone else has had this problem.

I'm rebuilding an existing WinForms application to use WPF. I'll be using the MVVM pattern in my new application. My old application makes extensive use of ADO; specifically, I have Row objects that wrap DataRow objects. And when I want to define what columns within a row can appear in a specific context in the UI, the definition lives in a RowView object.

Conceptually, "view" is an appropriate term for this - a single underlying DataRow can have multiple Row objects, each using a RowView object to define its subsets of its columns, access rights, etc, much as a view would in a SQL database. The ColumnView objects that in the RowView's ColumnViews collection contains metainformation about the presentation of each column in that specific view.

This is all hitting the MVVM pattern with a wet thud. In MVVM, "view" means something different: it means the UI's presentation of an object. My application's RowView isn't a view, as far as MVVM is concerned. To MVVM, there isn't really a RowView object as such, but there's an underlying RowViewModel that supports the interaction logic between the UI and a specific Row object, and an underlying ColumnView object for each of the row's columns.

Usually, terminological confusion emerges from category errors, but in this case I think I've got the categories right; the problem is that different contexts use the same name for different things.

The naive answer when that happens is "namespaces," but while using namespaces to disambiguate these terms will certainly work technically, I have serious doubts that it will unravel the confusion a new developer experiences when stumbling across this code one bit.

Another possibility is changing the name of the Row object to something else. Like, I could use "row" and "column" in the model, and "record" and "field" in the view and view model. So I could compose a Record from a Row and RowView, and a Field from each column value and ColumnView. Then I could have RecordViewModel and FieldViewModel objects that get exposed to WPF, and the UI developer would never have to know that such things as RowView and ColumnView objects existed. But this kind of stinks too.

Has anyone else run across this kind of problem while rebuilding software to use MVVM? What the heck did you do?

Answer 1

I would prefer to append things in these cases, sort of in a reverse Hungarian notation fashion.

• *ModelView or *DataView for models (Example: ExpenseModelView or ExpenseDataView)
• *UIView for the views themselves (Example: ExpenseUIView)

Personally I use namespaces and a small collection of conventions. I know where my models are and how they are used because I use them consistently throughout the application as well as my VMs and Views. I can tell the difference between a View, ViewModel, or a Model by how and where it is used or referred to and I think you will find that you do, too.

However, if you find that this affects your on boarding of new developers or you are having trouble coming up with consistent conventions, you can try the Hungarian-esque naming conventions to differentiate types a little.