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

Question

I am thinking of making all my entities 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 ?

Answer 1

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.