您是否为域模型中的每个公共类定义了一个接口？ 优点和缺点？
您是否为域模型中的每个公共类实现了一个接口？ 优点和缺点？
更新：如果存储库接口和域模型类在单独的程序集中定义，如果我们不为每个域类定义接口，是否会出现循环依赖。
Do you implement an interface for every public class in your domain model? Pros and Cons?
Update: If Repositories interfaces and domain model classes are defined in separate assemblies, wouldn't there be circular dependency if we do not define interfaces for every domain class.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
不，
缺点。
No.
Cons.
您应该为层之间的依赖关系定义接口，而不是为每个类定义接口。 因此，您的服务层应该依赖于存储库接口，而您的表示层应该依赖于服务接口。 除此之外，没有太多硬性规定，只要在有意义的地方使用它们即可。
常识是任何优秀设计的重要组成部分。
You should define interfaces for dependencies between layers, not for every class. So your Service layer should depend on a repository interface, and your presentation layer should depend on a service interface. Past that, there aren't many hard and fast rules, other then use them where it makes sense.
Common sense is a good part of any good design.
接口可以通过为类在特定情况下扮演的角色命名来使代码更具表现力。 一个类可能扮演多个角色。 例如，当人与猫交互时，猫可能有宠物界面，而当老鼠与猫交互时，猫可能有捕食者界面。
您可能会发现模拟角色，而不是对象是一本相关且有趣的读物。
Interfaces can be used to make the code more expressive by giving a name to the role a class is playing in a particular situation. A single class may play more than one role. For example when a Man is interacting with a Cat, the Cat might have a Pet interface, whereas when a Mouse is interacting with a Cat, the Cat might have a Predator interface.
You might find Mock Roles, not Objects a relevant and interesting read.
不。仅连接您当时需要的接口。 如果您尝试过早思考，您的代码将变得复杂且难以维护。 不久之后，程序员就会放弃这些接口，因为很难遍历所有接口来弄清楚需要什么。 任何为了做而做的事情都会导致灾难。
No. Only interface what you need at the time. If you try and think ahead too far soon, your code will become complex and unmaintainable. In a little while, programmers will ditch the interfaces becuase its too difficult to wade through all of them to figure out what is needed. Anything done for the sake of doing will lead to disaster.
从我的角度来看，这是矫枉过正了。 只是我的2分钱...
From my point of view, it is overkilled. Just my 2 cents...
不，我不这样做...
如果目前没有必要，为什么要这样做？
如果将来证明它是必要的（所有这些“应该”表明它是 YAGNI），您可以执行“提取接口”重构。
（现代 IDE 使这变得非常容易）。
No, I don't do it ...
Why would you do it, if it is not necessary at the moment being ?
If it should turn out in the future, that it should be necessary (al those 'shoulds' indicate that it is a YAGNI), you can perform an 'extract interface'-refactoring.
(Modern IDE's make it very easy to do so).
我可能会在下一个 Asp.Net 项目中这样做。
我的原因是，我们当前的项目需要在某个地方存储一些与 UI 相关的额外状态。 如果我们使用了域模型类的接口，我们就可以在用户控制代码中对实体类进行子类化，并用我们自己的具有额外状态的类进行替换。
我知道，这看起来有点脏。 我希望有一些类似于 Java 的 Seam 框架和对话机制的东西。
I might do it in my next Asp.Net project.
My reason is that we in the current project needed somewhere to store some extra state that were related to the UI. If we had used interfaces for the domain model classes we could right in the user control code subclasses the entity class and replaced with our own class that had that extra state.
I know, it seems kind of dirty. I'd love to have something along the lines of Java's Seam framework with the conversation mechanisms.
这取决于项目的类型。 如果您正在编写一个将被大量重用的 API（例如 Sharepoint API 包装器），我会更倾向于这样做。
对于其他不会被大量重用的项目，默认情况下，我不会强调为每个公共类都有一个接口。 相反，我会专注于使用设计良好的界面链接各层。
It depends on the type of project. If you are writing an API that will be heavily reused (such as a Sharepoint API wrapper), I would lean more towards doing this.
For other projects that will not be reused as heavily, and by default, I would not stress having an interface for every public class. I would instead concentrate on having layers linked using well-designed interfaces.
从不变性的角度来看，您可能会考虑在域对象上放置接口：
在代码中的大多数地方，您会希望对象是不可变的，这样您就可以保证它们不会被更改 - 在这种情况下，您可以工作使用某种返回接口的数据访问对象，确保您的域对象无法更改。
如果您正在编写某种管理页面，其中用户最终将编辑域对象，则您需要公开设置器 - 您的数据访问对象将需要返回“MutableDomainObject”实例（类或子接口） ）。
话虽如此，我还是同意上面表达的 YAGNI 哲学——如果你目前不需要保证不变性，那么目前可能不值得对此进行投资。 稍后分解接口应该不会太困难。
From the perspective of immutability you might consider putting interfaces on your domain objects:
In most places in your code you'll want your objects to be immutable, so that you can guarantee they won't be changed - in this case you'd work with a data access object of some kind that returns the interface, ensuring that your domain object can't be altered.
If you are writing an admin page of some sort where the user will end up editing the domain object, you'll need to expose setters - your data access object will need to return 'MutableDomainObject' instanaces (either a class or a sub-interface).
Having said that, I agree with the YAGNI philosophy expressed above - if you don't need to guarantee immutability at the moment, it may not be worth investing in this at the moment. It shouldn't be too difficult to factor out interfaces at a later date.