DDD：您松散耦合实体的充分理由是什么？
早在 12 月，就有 这篇文章 的回答是“可以使用具体类型[对于简单对象]”。
但我不断在示例项目中看到越来越多带有接口的简单实体，甚至是我刚刚控制的非常大的企业应用程序（数起来有 89 个接口）。
是不是人们没有选择最好的方法，只是用“我的项目是松散耦合的！”来对项目进行猛烈攻击？ 方法？
或者，我错过了什么吗？ 我可以使用具体类型对我拥有的 IService、IFactory 和 IRepository 实现进行单元测试（并且工作得很好）。 我还在构建我的第一个“反腐败层”，用于将许多第三方工具从主域中抽象出来。 这个反腐败层有许多外观、转换器和适配器——所有这些都是松散耦合的（或计划是松散耦合的）。
那么，对于具有接口的实体，我是否缺少一些东西？
public interface IContent
{
Int32 ContentID {get; set;}
}
IList<IContent> list = new List();
编辑：我还应该提到的是，我拥有的企业应用程序具有所有这些接口，并且单元测试为零。 哈哈
Back in December, there was this post that was answered with "it is ok to use concret types [for simple object]".
But I keep seeing more and more simple entities with interfaces in sample projects, and even the very large Enterprise application I just took control over (counting 89 interfaces and going).
Is it that people are not picking the best approach, and just shotgunning the project with the "my project is loosely-coupled!" approach?
Or, am I missing something. I can unit test with concret types for my IService, IFactory and IRepository implmentations I have (and works quite well). I am also building my first "Anticorruption Layer" for abstracting a lot of these 3rd party tools out away from the main domain. This anticorruption layer has a number of Facades, Translators, and Adapters - all of which are loosely coupled (or planned to be).
So, is there something I missing about Entities having Interfaces?
public interface IContent
{
Int32 ContentID {get; set;}
}
IList<IContent> list = new List();
Edit: I should also mention that that the enterprise app I have that has all of these interfaces, has zero unit tests. lol
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
具有责任的实体遵守接口比简单数据对象更重要。 如果您可以根据方法定义实体，那么，是的，您将从接口中受益。 我看不出在应用程序中简单地用作 DTO 的对象会通过拥有接口获得任何巨大的优势。
也就是说，在我看来，抽象出由第三方工具或 L2S 这样的框架创建的“实体”肯定是有好处的。
It is more important that entities that have responsibility conform to an interface than it is for simple data objects. If you can define the entity in terms of methods, then, yes, you'll benefit from an interface. I can't see that an object that will simply be used as a DTO within the application gains any great advantage by having an interface.
That said, there is certainly benefit from abstracting away "entities" created by a third party tool, or a framework like L2S, in my opinion.