使用域实体的一对一接口是好还是坏的做法？为什么？

问题描述

我在一些DDD企业应用程序中看到的一件事就是使用与域实体相同的接口，通过一对一的属性和功能映射。实际上，域对象总是通过它的一对一接口使用，所有域实体都有一个一对一的接口。

例如：

域对象帐户：

  public class帐户：IAccount 
 {
 public string Name {get; set;} 
 //...s更多字段也在IAccount 
 public decimal Balance {get; set;} 
 
  

它的匹配界面

  public interface IAccount 
 {
 string Name {get; set;} 
 // ...帐户
中的所有字段; set;} 
} 
  

但是最近我越来越相信这是，事实上，这是一种反模式。

我在开源社区的一些建筑师那里运行它，他们说这是基于设计错误或缺陷，在设计链的某个位置。 >

所以我告诉我的同事们y应该退出为Domain对象创建接口。因为他们没有任何目的，只要您更新域实体，您必须更新该界面。

首先声称这些接口提供了去耦，但我反驳说，因为接口与他们所做的域实体有一对一的关系没有真正提供任何解耦，对接口的改变意味着域实体的变化，反之亦然。

下一个声明是我们需要接口进行测试。我的柜台是犀牛嘲笑提供了混凝土课程的嘲笑和扼杀。但他们声称犀牛嘲笑有具体课程的麻烦。我不知道我是否购买，即使犀牛嘲笑有具体的课程，这并不一定意味着我们应该使用域实体的接口。

所以我很好奇：

为什么你的域实体有一对一的接口？

为什么这是一个好或坏的做法？

感谢阅读！ p>

编辑：我应该注意到，我一直都在使用界面，我相信如果被调用，我将使用一个接口一顶帽子。但是我具体指的是具有一对一接口的域实体。

解决方案

这是一个坏的做法， ...

没有特定的原因，您的界面需要与域实体不同;有时它真的是正确的映射。但是总是这样的事情是可疑的。关注的问题是接口是否真正设计，或者是否因为缺乏时间/懒惰而被投入使用。

使用您的示例，您描述的IAccount界面在Account对象上公开了getter和setter;似乎有点奇怪，不太可能，使用一个帐户的所有东西都需要设置帐户的余额，这个隐含的权限是在该级别的界面上指定的。您的系统中没有任何地方只想检查但不设置帐户余额？

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.

For example:

Domain object Account:

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

And it's matching interface

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.

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.

So I'm curious:

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

Why not?

Why is it a good or bad practice?

Thanks for reading!

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.

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?

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