Why would be the drawback of forcing my domain objects to implement INotifyPropertyChanged?

I am thinking of making all my enti开发者_开发百科ties in my domain model implement INotifyPropertyChanged . My main reason behind this would be:

If some entity gets changed in the domain the presentation layer would immediately know about it and change accordingly (I am trying to implement the MVPVM pattern and the presentation objects are not the same as domain objects). I think should make it easier for me.

What do you think are the drawbacks ?

Domain Models should mainly model the domain, so that is its primary responsibility. As Arnis L. put it in another answer, the domain model should not contain presentation layer stuff, and I can only agree.

However, pragmatically, I consider INotifyPropertyChanged (INPC) one of the more benevolent interfaces available. Although its main purpose is to support UI frameworks (both Windows Forms and WPF use it), it is mainly a signaling mechanism. Apart from the amount of work involved in implementing it, it doesn't do much harm.

By default I wouldn't implement it in my domain objects, but if I end up needing some kind of signaling mechanism (perhaps required by my View Models), I wouldn't hesitate to apply it. After all, even if the SRP states that a class should only have a single responsibility, such a class is still the type best suited for the task. No other class knows better when its state changes than the class itself.

So if you need a signaling mechanism in the Domain Model, then go ahead and implement INPC - there's no reason to invent a new one. The interface is defined in System.ComponentModel, so that also gives you a pretty good idea that it isn't tied to a particular UI framework.

The main drawback of implementing INPC is the amount of work involved, so I would only implement it as needed.

You answered it yourself. Single responsibility principle is the key.

I mean - your domain objects should NOT contain presentation layer stuff (or any other layer your pattern you follow has). That is not their job.

You can't be a professional boxer and ballet dancer at the same time.

I'm currently having the same discussion with my colleagues. One of the suggestions is indeed to implement NotifyPropertyChanged in the domain model, and use these object to bind to the UI.
Another suggestion is to leave the domain model alone, and create a presentation layer which wraps or decorates the domain model. The question with this approach is: how do you propagate business rules implemented in the domain model to the UI?
For example, a business rule is: "When a location changes, the status has to be cleared". This can easily be implemented in the domain model, but if you use a separate objects to bind the UI, this rule needs to be implemented again. At the moment at least I don't see another way of doing this.

Any thoughts?
(btw I'm talking about a fairly simple domain model which is populated by a webservice)