1

私は、DTO が POCO であるべきか、またはそれが任意のテクノロジに依存する可能性があるかについて、あまり確信が持てません。疎結合をサポートし、どのテクノロジーでも動作することを確認するには、それらを POCO として保持する方がよいと考えています。

サービススタックのドキュメントから それは言及されています：

ServiceStack で Web サービスを定義するために使用される要求と応答の DTO は標準の POCO ですが、実装はテスト可能で依存関係のない IService から継承する必要があります。DTO を別の依存関係のない .dll に保持することのボーナスとして、コード生成を一切行わずに厳密に型指定された API を提供する C#/.NET クライアントでそれらを再利用できます。また、DTO はすべてを定義します。サービス スタックは、追加のカスタム アーティファクトやマークアップで Web サービスを汚染しません。

しかし、DTO の実際の実装を見ると、サービス スタックに依存しています。

[Route("/todos")]
[Route("/todos/{Ids}")]
public class Todos : IReturn<List<Todo>>
{
    public long[] Ids { get; set; }
    public Todos(params long[] ids)
    {
        this.Ids = ids;
    }
}

[Route("/todos", "POST")]
[Route("/todos/{Id}", "PUT")]
public class Todo : IReturn<Todo>
{
    public long Id { get; set; }
    public string Content { get; set; }
    public int Order { get; set; }
    public bool Done { get; set; }
}

ドキュメントに記載されている内容と実際に実装されている内容と完全に混同しています。DTO をテクノロジーに依存させる必要があるのはなぜですか。DTO をクリーンに保ち、テクノロジーに依存しない方がよいのです。

私の理解は完全に間違っているかもしれません。

4

1 に答える 1

3

DTO に追加されたすべてのメタデータ属性は、依存関係があり、impl-free のServiceStack.Interfacesプロジェクトに格納されます。DTO に注釈を付けると、新しい APIでカスタム ルート属性を再利用し、フォールバックの事前定義されたルートではなくプリティ URL を使用してサービスを呼び出すことができるC# クライアントが利用できるという利点があります。

IReturn<T>インターフェイス マーカーを使用すると、この回答に見られるように、より簡潔に型指定された API 呼び出しが可能になります。

ServiceStack のビルトイン fluent API を使用してカスタム ルートを定義できるため、属性を使用する必要はありません。

public void Configure(Container container)
{
    Routes
      .Add<Todos>("/todos")
      .Add<Todos>("/todos/{Id}")
      .Add<Todo>("/todos", "POST")
      .Add<Todo>("/todos/{Id}", "PUT");
}
于 2013-05-01T13:04:48.263 に答える