1

Assume that there's a PIModel (i.e. Personal Information Model) and a ViewModel (contains some information from PIModel and other).

public PIModel
{
    private string firstName;
    public string FirstName { get; set; }

    private string lastName;
    public string LastName { get; set; }

    ... // other
}

The FirstName and LastName properties need to be bound to View, so I have two questions:

  • Does the ViewModel have a property reference to a PIModel instance?
  • If so, does the ViewModel have property references to PIModel.FirstName and PIModel.LastName?

I learned that implementing INotifyPropertyChanged in the Model is not recommended.

Clonkex
  • 3,373
  • 7
  • 38
  • 55
SubmarineX
  • 850
  • 5
  • 19
  • 38

2 Answers2

2

After a few years practicing MVVM, I would nuance a bit the answer, even if it is not 100% MSDN compliant.

I would strongly agree with this reccomandation: do not implement the INotifyPropertyChanged in Model.

And I would explain why: if your model is nothing but properties and INotifyPropertyChanged, what is its role in term of responsability? (Think about Single Responsability Principle: http://en.wikipedia.org/wiki/Single_responsibility_principle)

Let's take your example: if you use INotifyPropertyChanged in PIModel, then the role of PIModel is to present your data to your view. And by the way, what's the role of a ViewModel in the MSDN definition? You got it: present your data to your view.

So in the end, if you use both Model and ViewModel to present your data, the role of each component will blur, and you will have some ideas like "well, I think here I do no even need a ViewModel". The data presentation responsability will be set in different conceptual class.

In my opiniion if you have this kind of thought, you need ONLY ViewModel (but probably a bigger ViewModel containing beyond others PIViewModel). Do not build an anemic Model (model with only properties and no responsability at all), because it will complexify your code and add no value.

Use a Model only if you add some other responsability to your object, and not display responsability (because it belongs to a ViewModel) but rather real business responsability.

So if the most of data is get from server, and the most of business responsability is on the server, it will be logical for me to see mainly ViewModel in your client application.

Hope it helps.

Ouarzy
  • 3,015
  • 1
  • 16
  • 19
  • "it will be logical for me to see mainly ViewModel in your client application." I'm not quite understand this sentence, could you speak more specifically? – SubmarineX Sep 12 '13 at 07:44
  • Now, I'm confused that who create the model instances and hold them at first. – SubmarineX Sep 12 '13 at 08:18
  • I mean: your client will almost only perform soe display. In this case why would you need some model if there is no business logic? Juste create a PIViewmdel and use it to display your data. – Ouarzy Sep 12 '13 at 11:14
  • For instance, If I need to add one person, where the method should be placed, Model layer or ViewModel layer? Although the most of data is got from server, in client there're some method such as add, delete, modify, etc. then actually pass the required parameters to server and process corresponding operation such as add, delete, modify, etc. – SubmarineX Sep 12 '13 at 13:43
  • "If I need to add one person, where the method should be placed" => A person should be obtain through a service or a repository. Your service could directly return a ViewModel if no business logic is required in your object. Still, this is my MVVM adaptation and maybe hard to explain in just a stackoverflow answer, as it is inspired from Domain Driven Design approach. You may prefer use the MSDN vision and find some help on other threads like here: http://stackoverflow.com/questions/2650242/mvvm-thin-viewmodels-and-rich-models?rq=1 – Ouarzy Sep 12 '13 at 14:45
  • Sorry, I could not say clearly. It's that adding a person means user add a person information through UI. – SubmarineX Sep 13 '13 at 01:14
1

There is no problem if your model is self notifying. You can have your model INotifyPropertyChanged implemented. Here is the msdn article, it will clarify all the doubts you have regarding model implementation and the work around if your model is not implemneting INPC.

http://msdn.microsoft.com/en-us/library/gg405484%28PandP.40%29.aspx

So if your models do not fall in category where you can implement INotifyPropertyChanged (e.g database autogenerated entities) then you will have to write wrapper properties over model proerties in VM.

But frankly if you can implement INPC you should, as it saves from unnecessary duplication and maintainance of code.

Nitin
  • 18,344
  • 2
  • 36
  • 53
  • The application is with Client/Server model and without database in Client. The most of data is get from server. In this case, how should I do? – SubmarineX Sep 12 '13 at 03:02
  • So you have self defined models right which you bind to view via viewmodel? – Nitin Sep 12 '13 at 03:20
  • sorry, I'm not quite understand you said, could you speak more specifically? – SubmarineX Sep 12 '13 at 05:32
  • I have got some answer in "Why Use a ViewModel?" part which from http://msdn.microsoft.com/en-us/magazine/ff798279.aspx. – SubmarineX Sep 12 '13 at 05:37