您是否为域模型中的每个公共类实现了一个接口？优点和缺点？
更新：如果 Repositories 接口和域模型类在单独的程序集中定义，如果我们不为每个域类定义接口，就不会有循环依赖。
StackUnderflow
问问题
1479 次
9 回答
13
不。
缺点。
- 噪声代码。
- 更多要写。
- 雅尼。
于 2009-02-17T19:31:17.473 回答
7
您应该为层之间的依赖关系定义接口，而不是为每个类定义接口。因此，您的服务层应该依赖于存储库接口，而您的表示层应该依赖于服务接口。除此之外，没有太多硬性规定，除了在有意义的地方使用它们。
常识是任何优秀设计的重要组成部分。
于 2009-02-17T19:39:15.407 回答
2
通过为类在特定情况下所扮演的角色命名，可以使用接口使代码更具表现力。一个类可能扮演多个角色。例如，当人与猫交互时，猫可能有一个宠物接口，而当鼠标与猫交互时，猫可能有一个捕食者接口。
您可能会发现Mock Roles，而不是 Objects是相关且有趣的读物。
于 2009-02-17T19:53:22.737 回答
0
不，只连接你当时需要的东西。如果你想得太早，你的代码将变得复杂和不可维护。过一会儿，程序员就会放弃接口，因为它太难遍历所有接口来弄清楚需要什么。为了做而做的任何事情都会导致灾难。
于 2009-02-17T19:31:04.260 回答
0
从我的角度来看，这是矫枉过正。只是我的2美分...
于 2009-02-17T19:31:26.147 回答
0
不，我不这样做......如果目前没有必要，你为什么要这样做？
如果将来它应该变成必要的（那些“应该”表明它是 YAGNI），您可以执行“提取接口”重构。
（现代 IDE 使得这样做非常容易）。
于 2009-02-17T19:33:27.887 回答
0
我可能会在我的下一个 Asp.Net 项目中这样做。
我的原因是我们在当前项目中需要在某个地方存储一些与 UI 相关的额外状态。如果我们为域模型类使用了接口，我们可以在用户控制代码中对实体类进行子类化，并用我们自己的具有额外状态的类替换。
我知道，这似乎有点脏。我希望有一些类似于 Java 的 Seam 框架和对话机制的东西。
于 2009-02-17T19:38:19.343 回答
0
这取决于项目的类型。如果您正在编写一个将被大量重用的 API（例如 Sharepoint API 包装器），我会更倾向于这样做。
对于其他不会被大量重用的项目，默认情况下，我不会强调每个公共类都有一个接口。相反，我会专注于使用精心设计的界面链接层。
于 2009-02-17T19:40:16.810 回答
0
从不变性的角度来看，您可能会考虑将接口放在域对象上：
在代码中的大多数地方，您都希望您的对象是不可变的，这样您就可以保证它们不会被更改 - 在这种情况下，您将使用某种返回接口的数据访问对象，确保您的域对象无法更改。
如果您正在编写某种管理页面，用户最终将在其中编辑域对象，则您需要公开设置器 - 您的数据访问对象将需要返回“MutableDomainObject”实例（类或子接口）。
话虽如此，我同意上面表达的 YAGNI 哲学——如果你现在不需要保证不变性，那么目前可能不值得投资。以后排除接口应该不会太难。
于 2009-02-17T19:49:46.600 回答