【发布时间】：2010-10-08 04:29:01
【问题描述】：
您是否为域模型中的每个公共类实现了一个接口？利弊？
更新：如果 Repositories 接口和域模型类在单独的程序集中定义，如果我们不为每个域类定义接口，不会存在循环依赖。
【问题讨论】：
-
为什么您的实体程序集依赖于您的存储库程序集？一切都应该依赖于实体，实体应该不依赖任何东西
标签： c# interface dependencies loose-coupling
【发布时间】：2010-10-08 04:29:01
【问题描述】：
没有。
缺点。
- 噪音代码。
- 还有更多内容。
- 雅格尼。
【讨论】：
-
"2. 写得更多" 正确完成 = 在维护模式下写得更少。
-
似乎我不熟悉术语“维护模式”。你能解释一下吗？或者可以作为例子？
-
在可维护性方面，大量违反代码的毫无意义的 YAGNI 胜过架构灵活性
-
但是域上的接口没有灵活性。
您应该为层之间的依赖关系定义接口，而不是为每个类。因此，您的服务层应该依赖于存储库接口，而您的表示层应该依赖于服务接口。除此之外，没有太多硬性规定，除了在有意义的地方使用它们。
常识是任何优秀设计的重要组成部分。
【讨论】：
通过为类在特定情况下所扮演的角色命名，可以使用接口使代码更具表现力。一个类可能扮演多个角色。例如，当人与猫交互时，猫可能有一个宠物接口，而当鼠标与猫交互时，猫可能有一个捕食者接口。
您可能会发现Mock Roles, not Objects 是一本相关且有趣的读物。
【讨论】：
没有。只连接你当时需要的东西。如果你想得太早，你的代码将变得复杂和不可维护。过一会儿，程序员就会放弃接口，因为它太难遍历所有接口来弄清楚需要什么。为了做而做的任何事情都会导致灾难。
【讨论】：
在我看来，这太过分了。只是我的 2 美分...
【讨论】：
不，我不这样做... 如果暂时没有必要，你为什么要这样做？
如果它在未来出现，应该是必要的（那些“应该”表明它是 YAGNI），您可以执行“提取接口”重构。
（现代 IDE 让这一切变得非常容易）。
【讨论】：
我可能会在我的下一个 Asp.Net 项目中这样做。
我的原因是我们在当前项目中需要在某个地方存储一些与 UI 相关的额外状态。如果我们为领域模型类使用了接口，我们可以在用户控制代码中对实体类进行子类化，并替换为我们自己的具有额外状态的类。
我知道，它看起来有点脏。我希望有一些类似于 Java 的 Seam 框架和对话机制的东西。
【讨论】：
-
即使没有接口，你仍然可以扩展一个类......
-
是的，因为其他开发人员开始谈论接口，我没有想到这个简单的事实。 脸红
这取决于项目的类型。如果您正在编写一个将被大量重用的 API（例如 Sharepoint API 包装器），我会更倾向于这样做。
对于其他不会被大量重用的项目，默认情况下，我不会强调每个公共类都有一个接口。相反，我会专注于使用精心设计的界面链接图层。
【讨论】：
从不变性的角度来看，您可能会考虑将接口放在域对象上：
在代码中的大多数地方，您都希望您的对象是不可变的，这样您就可以保证它们不会被更改 - 在这种情况下，您将使用某种返回接口的数据访问对象，确保您的域对象不能被更改。
如果您正在编写用户最终编辑域对象的某种管理页面，您将需要公开设置器 - 您的数据访问对象将需要返回“MutableDomainObject”实例（类或子接口）。
话虽如此，我同意上面表达的 YAGNI 哲学 - 如果您目前不需要保证不变性，那么目前可能不值得投资。以后排除接口应该不会太难。
【讨论】：