INotifyPropertyChanged - Data Access, Business or UI layer

Question

We've had a bit of a discussion between myself and a few fellow colleagues in terms of the best layer to have INotifyPropertyChanged implemented. Here's the scenario:

Data Access Layer returns a collection of simple objects
Business Layer massages the objects and performs extra validation, etc
UI Layer binds to objects and uses INotifyPropertyChanged for change tracking

The scenario here is that the data returned by the DA layer is the same data that is consumed by the UI layer. Do we implement INotifyPropertyChanged in the UI layer and thus have multiple near-clones of the same object throughout the different layers or do we implement INotifyPropertyChanged in the DA layer, adding unnecessary complexity to the layer that is not concerned with property change tracking.

Concerns:

Having a separate object for DA, Business and UI layer is clean but adds a lot of redundancy
Implementing INotifyPropertyChanged in DA feels wrong as DA is not concerned with this concept, potentially coupling DA and UI layers

My personal preference in this scenario is:

public class DaObject
{
    public virtual string Value { get; set; }
}

// May or may not need a business object here. DA and UI may be enough.
public class BusinessObject : DaObject
{
    // Business layer logic/validation here...
}

public class UiObject : BusinessObject, INotifyPropertyChanged
{
    public override string Value
    {
        get { return base.Value; }
        set
        {
            base.Value = value;
            NotifyOfPropertyChanged(nameof(Value));
        }
    }

    // INotifyPropertyChanged implementation here...
}

Thanks!

user_806379 · Answer

The purpose of INotifyPropertyChanged is to notify clients that a property has been changed. In most cases the client will be a binding client, such as the UI layer.

The danger of implementing INotifyPropertyChanged in business logic or data access layers is you're adding complexity and likely adding potential performance issues which can cripple your application in the long term.

I would say - just because you can do something, doesn't mean you should.

This question is 4 years old, and the reason I came to read it is because I'm working on a legacy application which implemented INotifyPropertyChanged on the business logic/data access layer. As a result we have huge collections of objects with unnecessary Events, and a terrible performance hit.

I find it much better to keep business logic and business objects clean, only utilising INotifyPropertyChanged on View Models where necessary.

INotifyPropertyChanged - Data Access, Business or UI layer

1 Answers