3

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.

Community
  • 1
  • 1
Payal D'Cruz
  • 63
  • 6

2 Answers2

2

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.

Matthew Walton
  • 9,809
  • 3
  • 27
  • 36
  • Matthew, Thanks!An INotifyPropertyChanged implementation is the very "code level trait" of a ViewModel. Specific to my project, the values of the underlying model can change behind the scene. So how would my ViewModel know of this ? My model really does not have an INotifyPropertyChanged that the ViewModel can subcribe to (and if it did have a PropertyChanged handler, its just not a Model.. its a ViewModel). I feel for this specific requirement the textbook MVVM is just not happening – Payal D'Cruz Mar 19 '13 at 09:17
  • You can wrap your model in a class that implements INPC. However this does mean that you have lots of boilerplate code exposing each property and triggering propertychanged – failedprogramming Mar 19 '13 at 09:32
  • The usual design assumes that nothing else is going to change the model behind your back. If that's a possibility, the model has to provide a way to indicate that a change has happened. There are quite a few ways you can do that, INPC being only one of them, but it does require some active involvement from something which knows that the model has in fact changed. – Matthew Walton Mar 19 '13 at 10:30
0

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

Since (I assume) the model can be changed from any place, Your only other option would be to have 2 INPC's - One for Model-ViewModel and one for the ViewModel-View.

I personally don't like this approach. Too much flow and Refactoring issues (unless you use reflection - which is more code and lookups, But highly maintainable) Just try to physically separate the Model and ViewModel separately using a partial class. For example Employee.cs and Employee.ViewModel.cs. and group them - looks finer

Models need to be to be portable, INPC is fine with Portable Class Library so you could reuse the code across various targets

Ady
  • 104
  • 3