11

画面 DTO を使用してService LayerとPresentation Layerの間のデータをカプセル化するプロジェクトがあります。この場合、プレゼンテーション層は ASP.Net です。

DTO について知っている唯一のクラスは、サービス層クラスと、これらのサービスを呼び出して DTO を表示するページ/コントロールです。

DTO はほとんどの場合ページ/コントロール固有であるため、プレゼンテーション層に属していると思いますが、DTO を使用するには、サービス層がプレゼンテーション層を参照する必要があることを意味します。

私は、サービス層がより豊富なオブジェクトを返す必要があると考えています (ただし、ドメイン エンティティではありませんか?)。次に、プレゼンテーション層がこれらのオブジェクトを取得し、ページ/コントロールの懸念ごとに非常に具体的な DTO にマップできます。

ここにインターフェイス宣言と DTO があるので、私が話していることがわかります。

public interface IBlogTasks
{
    BlogPostDisplayDTO GetBlogEntryByTitleAndDate(int year, int month, string urlFriendlyTitle);
}

public class BlogPostDisplayDTO 
{
    public string Title { get; set; }
    public DateTime PostDate { get; set; }
    public string HtmlContent { get; set; }
    public string ImageUrl { get; set; }        
    public string Author { get; set; }
    public int CommentCount { get; set; }
    public string Permalink { get; set; }
}

編集

ドメイン モデルが関与しないユース ケースを説明する別のコード サンプルを次に示します。多分これは物事を少し明確にするでしょう。DTO の意味を過負荷にしていると思います。私は、ネットワーク上でオブジェクトを転送する機能のための DTO について話しているのではありません。サービス層への通信間の契約を形式化するために DTO を作成しています。

public interface IAuthenticationTasks
{
    bool AuthenticateUser(AuthenticationFormDTO authDTO);
}

public class AuthenticationFormDTO
{
    public string UserName { get; set; }
    public string Password { get; set; }
    public bool persistLogin { get; set; }
}

たとえば、私の認証で突然 IP アドレス パラメータが必要になったとします。コントラクト インターフェイスを変更せずに、そのプロパティを DTO に追加できるようになりました。

プレゼンテーション レイヤーにエンティティを渡したくありません。自分のコード ビハインドに移動機能を持たせたくないBlogPost.AddComment(new Comment())

4

2 に答える 2

18

「DTO」の標準的なユースケースは、より「ネットワーク経由で渡すことができるシリアル化可能なオブジェクト」であると考えられていましたが、この場合、実際には「presentation-transfer-objects」または「view-models」を参照しています。

通常、私たちのプロジェクトでは、これらがどこにあるのかという答えは、DDD ドメイン モデルを PTO クラスにマップする「変換」コードがどこにあるのかということです。それがプレゼンテーション層にある場合（おそらくそれほど素晴らしい答えではないでしょう）、プレス。layer は、PTO を宣言する場所です。しかし、多くの場合、翻訳を行うのは「サービス」であり、それは「サービス」レイヤーと「プレゼンテーション」レイヤーの両方が PTO への参照を必要とし、(通常) 別の宣言につながることを意味します。中立的なプロジェクト/アセンブリ/名前空間/プレゼンテーション層とサービス層の両方が参照できるものは何でも。

于 2009-01-30T11:57:29.103 に答える
4

実際のサービス (Web または WCF) を使用していますか? その場合は、サービス層で DTO を定義すると、サービス (ま​​たは古い ASMX を使用している場合は Web) 参照を追加するときに作成されるプロキシに、すべての DTO タイプが含まれます。これは最も簡単な方法であり、ASP.NET プロジェクトとサービス プロジェクトの間の疎結合のみを維持します。どちらの方向でもプロジェクトを直接参照する必要はありません。DTO を更新するときは、サービス参照を更新するだけで、生成されたプロキシ クラスを介して Web プロジェクトに更新が自動的に公開されます。

いずれにせよ、DDD アプローチのようなものに従っている場合は、インフラストラクチャ プロジェクト (Web プラットフォーム固有の UI など) でドメイン オブジェクトを参照するのが最善です。ただし、上記の私のアドバイスに従えば、Web プロジェクトはプロジェクトに直接依存することはまったくありません。これは良いことであり、Web プロジェクトに依存する豊富なドメイン オブジェクトを使用するよりも確実に優れています (たとえそうであったとしても)。考慮事項-これを行っているとは言っていないことに気づきました）。

DTO がビュー固有のものであれば、UI プロジェクトに含めます。ビューが必要なものだけをモデルから取得するようにするのは、実際にはコントローラーの仕事です。あなたの場合、ビューに必要なフィールドだけを持つ値オブジェクトです。

于 2009-01-30T01:13:34.147 に答える