DTOs的接口

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

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？依赖注入应该也不是重点。
任何启蒙都会非常有帮助。在最后学习新的东西和方法总是很好...

来源

2015-05-19 Simon Linder

如果你不需要它，没有理由使用接口。这太复杂了，应该是一个简单的对象。 –

如果* DTO *只是一个属性列表，我看到这一点毫无意义。例如，如果您有某种存储库，那么您可以通过接口来代替虚假表示的数据库连接。如果你有'Person GetPerson（）'，你可以拥有数据库版本和假版本。 – christiandev

对于类型约束和映射，您可能会在DTO（'FooDto：IAmADto'）上弹出标记接口，但除此之外，它的用途是什么？这里没有抽象，取决于'IPerson'给你的连接级别与'Person'完全相同。 –

DTOs转移状态 - 就是这样。通过容器注入它们或嘲笑它们进行测试似乎毫无意义（如果这是动机）并且完全没有必要。不要这样做。

来源

2015-05-19 16:27:49

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

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"}; 
    } 
}

你会使用与用于测试一些mock对象一个FakeRepo。

来源

2015-05-19 16:29:33 christiandev

我会理解它使用该接口的情况。在我的情况下，我从任何时候都可能是数据库的另一个服务中获取对象，并使用'Automapper'将这些对象映射到我的DTos。 –

正如我在上面的评论中所提到的，为简单的DTO提供接口是没有意义的。 – christiandev

回答

相关问题