c# - 在使用 Fluent NHibernate 映射时对接口(interface)进行编程

Question

我已被迫屈服并开始学习 Fluent NHibernate(之前没有 NHibernate 经验)。在我的项目中，我正在对接口(interface)进行编程以减少耦合等。这意味着几乎“一切”都指的是接口(interface)而不是具体类型(IMessage 而不是 Message)。这背后的想法是通过能够模拟依赖关系来帮助提高它的可测试性。

但是，当我尝试映射到接口(interface)而不是具体类时，(流畅的)NHibernate 并不喜欢它。问题很简单——根据 Fluent Wiki，定义我的类的 ID 字段是明智的，例如

int Id { get; private set; }

获取典型的自动生成的主键。但是，这仅适用于具体类 - 我无法在接口(interface)上指定访问级别，必须在同一行中

int Id { get; set; }

我想这否定了在具体类中将 setter 设为私有(private)(想法是只有 NHibernate 应该设置数据库分配的 ID)。

现在，我想我只是将 setter 公开并尽量避免写入它的诱惑......但是有没有人知道什么是“正确的”，创建正确的最佳实践方法只有 NHibernate 可以写入的主键字段，同时仍然只能对接口(interface)进行编程？

已更新

根据我在 mookid 和 James Gregory 的以下两个答案之后的理解，我很可能走错了路——我不应该像现在这样为每个实体设置一个接口(interface)。这一切都很好。我想我的问题就变成了——是否没有理由针对任何实体的接口(interface)进行 100% 的编程？如果甚至有一种情况可以证明这是合理的，是否可以使用(流畅的)NHibernate 来做到这一点？

我问是因为我不知道，不是为了挑剔。感谢您的回复。 :)

Answer 1

我意识到这是一种转移，而不是对您问题的回答(尽管我认为 mookid 已经涵盖了这一点)。

您应该真正评估您的域实体上的接口(interface)是否真的提供了任何有值(value)的东西；很少有实际需要这样做的情况。

例如:IMessage 与 Message 的依赖相比，两者(几乎)毫无疑问共享相同的签名，这两者之间的耦合度如何降低？您不需要模拟一个实体，因为它很少有足够的行为需要被模拟。