Why does an editing method in a List property use the get accessor?

I have a property of type List<T>, and I want to update a database whenever it's updated.

At first, I thought I could just update the database in the property's set accessor, but after some testing, I realized that methods like Add() and Remove() only use the get accessor, not the set one.

Why is this, and what can I do to work around it?

The class containing this property implements an interface which requires a List. Although I can change the property's type to BindingList in the interface, not all implementing members need to know when the property is updated.

Your property shouldn't have a setter to begin with. That property relates to the List object itself, not the items in the List. A setter would be used to replace the existing List object with a completely new List object. In order to call Add or Remove on the existing List object, you need to get that object from the property first, hence the getter is what is executed.

If you need to know when the existing collection object changes, only the collection itself can do that. That means using a BindingList<T> as you suggest, or an ObservableCollection<T>. The property itself should be read-only, e.g.

public ObservableCollection<object> Objects { get; } = new ObservableCollection<object>();

private void Objects_CollectionChanged(object sender, NotifyCollectionChangedEventArgs e)
{
    // ...
}

and:

Objects.CollectionChanged += Objects_CollectionChanged;

I'll start by restating the question using code snippets so we have actual identifier names to work with.

You have a class like this:

public class MyClass
{
    public List<string> MyList {get; set;} = new List<string>();
}

And you have an instance of MyClass:

var myInstance = new MyClass();

You then have code like this:

myInstance.MyList.Add("foo");

The question is why this uses the get accessor for the MyList property instead of the set, even though it changes the List<string> property.

The answer is the code starts from the myInstance object and then needs to GET the List<string> object referred to by the MyList property so it can call that list's Add() method. It doesn't matter that the Add() method changes the list. As far as the property access is concerned, you are still getting the reference, and nothing else.

So what is the set accessor for, then? Well... setting the reference. So now let's say you do this:

myInstance.MyList = new List<string>();

This uses the set accessor, because it sets a new value to the actual property and not just a property or member of the property. And now that you understand when the set accessor is actually called, hopefully that helps clarify why the get accessor is used in other situations: you did not assign a new value to the property.

Finally, this should raise the question of whether you want a set accessor for the property at all.

For many classes, completely changing a List used by the class is likely to break assumptions for other related aspects of the class. That is, you're probably better off declaring the property like this:

public class MyClass
{
    public List<string> MyList {get; private set;} = new List<string>();
}

or like this:

public class MyClass
{
    public List<string> MyList {get;} = new List<string>();
}

Because, again, anything you want to do with that specific list instance is a get operation, rather than a set, and so the set access is not really needed or even helpful.

It's probably easier to create and unit test the 4 CRUD methods to work on the list as you often have to do. But, if you really want a workaround you could use IList:

public class DatabaseList<T>: IList<T>
	where T: class, new()
{
	private List<T> _list;
		
	public DatabaseList()
	{
		_list = new List<T>();
		// populate from current database content?
	}

	public new void Add(T item)
	{
		_list.Add(item);
		// and do database Insert
	}
	
	// and the other 12 members of IList...
	//   which makes the 4 CRUD methods sounds like a lot less testing
}