DTO的接口

Question

我目前正开始开发大型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？依赖注入也不应该是重点。任何启示都会非常有帮助。最后，学习新的东西和方法总是好的...

Answer 1

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

Answer 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与某些模拟对象一起使用以进行测试。

Answer 3

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

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

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

那么您就不会更改程序的行为，也不会对已经存在的内容进行更改。

所以您也必须考虑您的api将会如何。