Where to implement INotifyPropertyChanged interface in software architecture?

I am at the moment creating a project large enough in my opinion to separate carefully the well-known layers in its architecture.

For the data access layer (DAL), I simply use the .NET Entity Framework.

For the business layer, I defined business objects which are then available to subsequent developers who can use them to create clients and handle the UI.

As I have to develop a client application as well for demonstration purpose, I realized that it can be very helpful to have an ObservableCollection&l开发者_如何学编程t;T> instead of a list, and that as often as possible the objects should implement the INotifyPropertyChanged interface so that the UI automatically detects the changes and displays the updates straightaway.

Yet, I wonder whether it is really the right way to do from a architectural point of view. That is, technically, I don't think the business layer should have anything to do with UI display as we do not really "know" what a programmer might use it for; he might just want to use the objects for computational purposes for example. Hence, I was wondering what was the common practice?

Should I implement these features in the business layer (there would be no performance issue)? Should I create some kind of "decorator" object in another layer which includes all these features?

As mentioned by Skliwz in the comments, the correct place to place this is in objects that are specifically bound to the UI layer.

If you are binding your business objects directly to the UI layer, and you find that the INotifyPropertyChanged interface doesn't really belong on your business objects, then it's a clear indicator that you should have different objects for different purposes

For example, you might want to have a view model, using the Model View View Model pattern.

However, if you find that your business objects are to be monitored by other systems, and you need notifications as to when they changed, then the INotifyPropertyChanged interface is appropriate. However, it sounds like in your specific case, it is not.