combining viewmodel with model

Question

Ok Here is another point to ponder.

MVVM states that Model is agnostic of ViewModel. So the ViewModel exposes properties for the View to bind through.

Microsoft Code Analysis rules tells me to add a property to my public variables in the Model.

warning : CA1051 : Microsoft.Design : Because field 'Employee.name' is visible outside of its declaring type, change its accessibility to private and add a property, with the same accessibility as the field has currently, to provide access to it.

Now its 2 repeated properties, I'd rather have it DRY and so I was thinking of Merging ViewModel and View. There's another thing here, the Model is a POCO, and Will have no INotifyPropertyChanged, so getting the VM to know of the change in Model values is another issue. I use a lot of IList based binding

Could there be a future issue I have overlooked ?

EDIT: I forgot to mention, I looked at how to correctly define Model to ViewModel relation?, One more thing in our software is that we have a separate entity that populates IList, Its a SERVICE/UTILITY Assembly. The EmployeeViewModel is in a separate VIEW Assembly. So I would not be able to return a ILIst.

Answer 1

Don't do it. I know it sounds like a lot of extra stuff you don't need, but it pays off as your applications get more complicated. I've found it absolutely essential to have a ViewModel to bind to that supports property notifications and lets me present data in a way that the view can easily consume, without being tied to representations in the Model - the ViewModel transforms between the two as required.

If you don't have these layers, changes to things in the future and particularly once you pass a certain level of complexity will become very difficult.

Now, whether you listen to Microsoft's advice about using public properties instead of public fields on your Model is up to you, but it is a good habit to get into if you need to put some logic into getters and setters later. Auto properties can be a good substitution for simple public fields at first, saving you having to declare a backing field before you actually need one.