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。

Answer 4

DTO 可以從多個接口繼承屬性，並且使用接口可以減少組件和模塊之間的轉換數據，尤其是在單個解決方案的邊界中。

此外，規則通常應用於接口，因此 DTO 應該使用它們。

Answer 5

我是網絡編碼的新手，所以這可能是錯誤的方向，但是我從數據庫中獲得了一個 DTO，我想為不同的視圖公開它的不同部分。 我已經使用單個 DTO 上的接口對此進行了編碼（使用條件序列化來確保只公開我想要的位）。 我還在傳入數據結構上使用接口，因此我可以使用相同的 DTO，但在我的單元測試中模擬它。