实体应该实现接口吗？
我个人没有我的实体实现接口。 对于Task类，我不会让ITask在其上定义相同的属性。
我已经看过它做了几次，所以我想知道这个建议来自哪里，以及你从中获得了什么好处。
如果你正在使用ORM，那么说“我可以改变我的数据访问”的论点是无关紧要的，那么还有什么其他理由呢？
更新：
关于INotifyPropertyChanged的评论中提出了一个很好的观点。 这不是我的观点 – 我说的是这样的事情：
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; } }
我曾经走过这条路（价值对象的接口）。 这是背后的皇室痛苦，我建议反对它。 它的共同论点是：
模拟：它们是价值对象。 没有嘲笑。 除了编写构建器（在Java中）或在C＃中使用命名参数之外，模拟最终会产生很大的痛苦。
Readonly views：我必须承认我仍然宁愿在默认情况下创建一些不可变的东西，只有在绝对需要时才使它变得可变。
隐藏function：一般来说，范围已经涵盖了这一个。
这样做的主要好处是，它是一种将您的实体暴露为“只读”版本的方式（只要您的界面当然不公开setter）。
我们正在进行相当多的unit testing，因此经常想要模拟我们没有测试的东西。 虽然我不喜欢它，但我们最终都在使用各种接口，因为它使得模拟事物变得容易多了。
从理论上讲，大多数模拟框架也可以模拟普通类，但实际上这会引起我们的问题，因为我们有时用reflection来做聪明的事情，而模拟类的类型与原始类不同。 这样做：
var myTask = MyIoCProvider.Get(); var taskType = typeof(myTask);
无法预测。 鉴于：
var myTask = MyIoCProvider.Get(); var taskType = typeof(myTask);
将您作为绝对派生自ITask的taskType。
所以接口只是给我们一种让我们的系统更具可模仿性的方法。
如果你在考虑使用DomainEvents而不是数据结构，比如任务确实需要实现一个接口
public interface IDomainEvent { Guid EventId { get; } Guid TriggeredByEvent { get; } DateTime Created { get; } } public class OrderCancelledEvent : IDomainEvent { Guid EventId { get; set; } Guid TriggeredByEvent { get; set; } DateTime Created { get; set; } // And now for the specific bit int OrderId { get; set; } }
或者类似地，如果你有一个公共数据访问层，可能需要接受IEntity的标准基类，但如果它只是你在post中描述的数据结构，我就没有每种类型的接口。
当您处理实际暴露行为的域对象时，您可能希望拥有用于unit testing的接口。