Question

I personally don’t have my entities implement interfaces. For a Task class I wouldn’t have ITask that just had the same properties defined on it.

I’ve seen it done a few times though, so I’m wondering where that advice comes from, and what benefits you get from it.

If you’re using an ORM then the argument that says “I can change my data access” is irrelevent, so what other reason is there for doing this?

UPDATE:
A good point was made in the comments about INotifyPropertyChanged. That wasn’t my point though – I’m talking about having something like this:

public interface ITask
{
    int Id { get; set; }
    string Description { get; set; }
}

public class Task : ITask
{
    public int Id { get; set; }
    public string Description { get; set; }
}

Answer 1

I went down this road once (interfaces for value objects). It was a royal pain in the backside, I recommended against it. The common arguments for it are:

Mocking:
They are value objects. Nought to mock. Plus mocking ends up being a large pain than either writing a builder (in Java) or using the named arguments stuff in C#.

Readonly views:
I must admit I still prefer to make something immutable by default, only making it mutable if absolutely required.

Hidden functionality:
Generally scope has covered this one for me.