使用与域实体的一对一接口是好还是坏的做法?为什么? [英] Is using one-to-one interfaces with domain entities a good or bad practice? Why?

问题描述

我在我从事的一些 DDD 企业应用程序中看到的一件事是使用与域实体相同的接口，具有一对一的属性和功能映射.事实上，域对象总是通过它的一对一接口来使用，并且所有域实体都具有这种风格的一对一接口.

One thing I see in some DDD enterprise apps that I work on, is the use of interfaces that are identical to the domain entities, with a one-to-one mapping of properties and functions. Indeed a domain object is always used through it's one-to-one interface, and all domain entities have a one-to-one interface in this style.

例如:

域对象帐户:

public class Account : IAccount
{
     public string Name {get;set;}
     //...some more fields that are also in IAccount
     public decimal Balance {get;set;}
}

和它匹配的接口

public interface IAccount
{
   string Name {get;set;}
   //... all the fields in Account
   decimal Balance {get;set;}
}

但最近我越来越相信这实际上是一种反模式.
我由开源社区的一些架构师运行它，他们说这是基于设计错误或缺陷，位于设计链的上游.

But lately I've become increasingly convinced that this is, in fact, an anti-pattern.
I ran it by some architects in the open source community, and they say that this is based on design mistakes or flaws, somewhere up the chain of design.

所以我告诉我的同事，他们应该停止为域对象创建接口.因为它们没有任何目的，并且每当更新域实体时都必须更新界面.

So I tell my colleagues that they should quit creating interfaces for the Domain objects. Because there is no purpose to them, and you have to update the interface whenever you update the domain entities.

首先声称这些接口提供了解耦"，但我反驳说，因为接口与域实体之间存在一对一的关系，它们并没有真正提供任何解耦，对接口的更改意味着域实体的变化，反之亦然.

First the claim was made that these interfaces provide 'decoupling', but I counter that because the interfaces have a one-to-one relationship with the domain entities that they do not really provide any decoupling, a change to the interface means a change in the domain entity and vice-versa.

下一个声明是我们需要用于测试目的的接口.我的反对意见是 Rhino-mocks 提供了对具体类的模拟和存根.但是他们声称 Rhino-mocks 在具体类上有问题.我不知道我是否买那个，即使 rhino-mocks 在具体类上有问题，这并不一定意味着我们应该为域实体使用接口.

The next claim is that we need the interfaces for testing purposes. My counter is that Rhino-mocks provides for the mocking and stubbing of concrete classes. But they claim that Rhino-mocks has trouble with concrete classes. I don't know if I buy that, even if rhino-mocks has trouble with concrete classes, that doesn't necessarily mean we should use interfaces for the domain entities.

所以我很好奇:

为什么要为域实体提供一对一的接口?

Why would you have one-to-one interfaces for your domain entities?

为什么不呢?

为什么这是好或坏的做法?

Why is it a good or bad practice?

感谢阅读！

编辑:我应该注意到我一直在使用接口，我相信如果需要的话，我会毫不犹豫地使用接口.但我特指具有一对一接口的域实体.

EDIT: I should note that I use interfaces all the time, and I believe that if it's called for I will use an interface at the drop of a hat. But I'm specifically referring to domain entities with one-to-one interfaces.

推荐答案

正如所描述的那样，这是一种糟糕的做法，但是...

It's a bad practice as described, but...

您的接口需要与域实体不同，没有具体原因；有时它确实是正确的映射.但令人怀疑的是，情况总是如此.值得关注的问题是界面是否真正设计，或者它们是否只是由于缺乏时间/懒惰而被扔到位.

There's no specific reason that your interfaces need to be different than your domain entities; sometimes it really is the right mapping. But it's suspicious that it's always the case. The point of concern there is a question of whether or not the interfaces were truly designed, or whether they were just thrown into place out of lack of time / laziness.

以您的示例为例，您描述的 IAccount 接口公开了 Account 对象上的 getter 和 setter；使用帐户的所有内容都需要设置帐户余额，并且隐含的权限是在该级别的接口中指定的，这似乎有点奇怪且不太可能.您的系统中是否没有您只想查看但不想设置帐户余额的地方?

To use your example, the IAccount interface you describe exposes getters and setters on the Account object; it seems a little odd and unlikely that everything that uses an Account will have a need to set the balance on the account, and that that implied permission is specified at that level of interface. Is there no place in your system where you want to merely check but not set the Account balance?

这篇关于使用与域实体的一对一接口是好还是坏的做法?为什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！