DTO 的接口答案

【问题标题】：Interfaces for DTOsDTO 的接口
【发布时间】：2015-05-19 16:21:33
【问题描述】：

我目前正在开发一个大型 Web 应用程序，主要包含一个 Angular SPA 和一个可以访问后端层的 OData WebAPI。
我们处于早期阶段，已经开始实现第一批类，包括位于公共命名空间中的 Model.dll，以便所有层都可以访问它。
我们现在正在讨论模型中的那些 DTO。有人说使用接口是绝对必要的，所以代码是这样的：

namespace MySolution.Common.Model
{
    public interface IPerson
    {
        int Id { get; set; }
        string Name { get; set; }
        ...
    }
}

namespace MySolution.Common.Model
{
    public class PersonDTO : IPerson
    {
        public int Id { get; set; }
        public string Name { get; set; }
        ...
    }
}

就是这样。只是没有更多智能的简单 DTO。
我现在问自己这是否真的是一个好方法，因为我没有看到在这里使用界面的必要性。
这样做有什么好处？提到了可测试性，但是否有必要测试 DTos？依赖注入也不应该是重点。
任何启蒙都会非常有帮助。最后学习新的东西和方法总是好的......

【问题讨论】：

如果您不需要接口，就没有理由使用它。这使应该是一个简单的对象过于复杂。
如果 DTO 只是一个属性列表，我认为这毫无意义。例如，如果您有某种存储库，那么您将连接它以替换数据库连接以获取虚假表示。如果你有Person GetPerson()，你可以有DB版本和Fake版本。
您可能会在 DTO (FooDto : IAmADto) 上弹出一个标记接口，用于类型约束和映射，但除此之外，它的用途是什么？这里没有抽象，取决于IPerson 为您提供与取决于Person 完全相同的耦合级别。

标签： c# interface dto

【解决方案1】：

DTO 传输状态 - 就是这样。通过容器注入它们或模拟它们进行测试似乎毫无意义（如果这是动机的话）并且完全没有必要。不要这样做。

【讨论】：

【解决方案2】：

作为一个例子，进一步我上面的评论：

Interface IRepo
{
  Person GetPerson(int id);
}

Public class DbRepo : IRepo
{
  public Person GetPerson(int id){//get person from database}
}

Public class FakeRepo : IRepo
{
  public Person GetPerson(int id)
  {
    return new Person {Id = id, Name = "TestName"};
  }
}

您可以将FakeRepo 与一些模拟对象 一起用于测试目的。

【讨论】：

我会理解为这种情况使用界面。就我而言，我正在从另一个服务获取对象，该服务可能随时是一个数据库，并使用 Automapper 将这些对象映射到我的 DTos。
正如我在上面的评论中提到的，拥有一个简单 DTO 的接口是没有意义的。
在这种情况下，您的 DTO 不是 DTO 是实体。

【解决方案3】：

我有这种情况，我正在编写一个应该松耦合的 api，因为我可以调整它的任何部分以表现不同，例如更改存储，或更改请求中的一些参数，所以它可以有另一种行为而不影响已经存在的行为。

考虑到这一点，为 DTO 提供一个接口是有效的，因为在其他时候它可以更改其属性以携带更多数据，并且您只需实现一个抽象，您将在其中使用这个新实现的 dto，就是映射新参数，在服务中用于注册记录。

然后您将接口（抽象）绑定到 dto 的新实现以及将要修改的地方。

那么你就不会改变你程序的行为，也不会改变已经存在的东西。

所以你也得想想你的 api 会是怎样的。

【讨论】：

【解决方案4】：

DTO 可以从多个接口继承属性，使用接口可以减少组件和模块之间的转换数据，尤其是在单个解决方案的边界中。

此外，规则通常应用于接口，因此 DTO 应该使用它们。

【讨论】：