DTO接口

Question

我目前正在开发一个大型web应用程序，主要包含一个Angular SPA和一个可以访问后端层的OData WebAPI
我们处于早期阶段，已经开始实现第一个类，包括一个模型。位于公共命名空间中的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，没有更多的智能
我现在问自己，这是否真的是一个好方法，因为我不认为有必要在这里使用界面<这有什么好处？提到了可测试性，但是否有必要测试DTO？依赖注入也不应该是重点<任何启示都会很有帮助。最后，学习新的东西和方法总是好的。。。




Answer 1

我遇到了这种情况，我正在编写一个应该松散耦合的api，因为我可以调整它的任何部分以使其行为不同，比如更改存储，或者更改请求中的一些参数，这样它就可以有另一种行为，而不影响已经存在的内容。

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

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

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

所以你也必须考虑你的api会是怎样的。

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

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