Welches Projekt Schicht sollte DTO-Bildschirm Live In?

Question

Ich habe ein Projekt, wo wir Bildschirm DTO verwenden, um die Daten zwischen dem Service Layer und Presentation Layer verkapseln. In unserem Fall ist die Präsentationsschicht ASP.Net.

Die einzigen Klassen, die über die DTO wissen sind die Service-Layer-Klassen und die Seiten / Kontrollen, die diese Dienste aufrufen und anzeigen der DTO.

Die DTO sind fast immer die Seite / Steuerung spezifisch, so fühle ich sie gehören in der Präsentationsschicht, sondern dass der Service Layer die Präsentationsschicht, um den DTO hätte verweisen würde bedeuten, zu verwenden.

ich fast denke, dass der Service Layer reiche Objekte zurückgeben sollte (aber nicht Domain-Einheiten?) Und dann kann die Präsentationsschicht diese Objekte nimmt und ordnet sie sehr spezifisch für DTO für jede Seite / Steuern betreffen.

Hier ist eine Interface-Deklaration und ein DTO so können Sie sehen, was ich rede:

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

Bearbeiten

Hier ist ein weiteres Codebeispiel einen Anwendungsfall zu beschreiben, wo das Domain-Modell nicht beteiligt ist. Vielleicht wird dies die Dinge ein wenig klären. Ich glaube, ich habe die DTO Bedeutung überlastet. Ich spreche nicht über eine DTO für die Funktion eines Objekts über den Draht Übertragung. Ich schaffe DTOs Verträge zwischen Kommunikation zu meinem Service Layer zu formalisieren.

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

Lassen Sie uns sagen, dass meine Authentifizierung ganz plötzlich eine IP-Adressparameter erfordert. Ich kann jetzt diese Eigenschaft auf den DTO hinzufügen, ohne dass mein Vertrag Schnittstelle ändern.

Ich will nicht Entities meine Presentation Layer zu übergeben. Ich möchte nicht mein Code hinter die Fähigkeit zu haben, zu BlogPost.AddComment(new Comment()) gehen

Answer 1

dachte Auch der kanonische Anwendungsfall für die ‚DTO‘ mehr „serializable Objekt, das über den Draht geführt werden kann“ ist in diesem Fall, dass Sie wirklich mehr zu ‚Präsentation-Transfer-Objekte‘ oder ‚view-Modelle beziehen ‘.

Typisch für unsere Projekte die Antwort auf, wo diese leben, wo die ‚Übersetzung‘ Code ist, dass die DDD-Domänenmodell abbildet auf die PTO-Klassen. Wenn das in der Prensenation Schicht (vielleicht nicht so groß, eine Antwort), dann der pres. Schicht ist, wo ich die PTOs erklären würde. Aber mehr als oft nicht, es ist der ‚Service‘, das die Übersetzung für Dich tut, und das bedeutet, dass sowohl der ‚Service‘ und die ‚Präsentation‘ Schicht für Referenzen auf die PTO und dass (in der Regel) führt zu ihrer Erklärung in einem separaten, neutral Projekt / Montag / Namensraum / was auch immer, dass sowohl der Präsentationsschicht und die Service-Schicht kann dann Referenz.

Answer 2

Sind Sie mit tatsächlichen Dienste (Web oder WCF)? Wenn ja, definieren dann die DTOs in der Dienstschicht und dem Proxy erstellt, wenn Sie einen Dienst hinzufügen Referenz (oder Web, wenn alte ASMX verwenden) werden alle der DTO-Typen enthalten. Dies ist der einfachste Weg, es zu tun, und behält nur lose Kopplung zwischen ASP.NET-Projekt und Ihrem Service-Projekt - kein direkter Projektverweis wird in beiden Richtungen erforderlich. Wie Sie Ihre DTOs aktualisieren, alles, was Sie tun müssen, ist Ihren Dienstverweis aktualisieren und es wird die Updates für Ihr Web-Projekt über die Proxy-Klasse, die generiert wird.

automatisch aussetzen

Auf jedem Fall, wenn Sie so etwas wie ein DDD Ansatz folgend sind ist es am besten Ihre Infrastrukturprojekte haben (wie zum Beispiel einer Web-Plattform-spezifische UI) Referenzierung Ihrer Domain-Objekte als umgekehrt. Wenn Sie meinen Rat oben folgen, aber Ihr Webprojekt wird keine direkte Abhängigkeit von dem Projekt überhaupt, was eine gute Sache ist, und sicherlich besser als Ihre reichen Domain-Objekte, die auf dem Web-Projekt abhängig (wenn dies auch eine Überlegung - ich weiß, Sie waren nicht sagen Sie dies taten)

.

Wenn Ihr DTOs Ansicht spezifisch sind, dann würde ich sie in Ihrem UI-Projekt gehören. Es sollte wirklich die Aufgabe des Controller sein, um sicherzustellen, dass die Ansicht nur von dem Modell bekommt, was er braucht -. In Ihrem Fall ein Wert-Objekt mit nur den Feldern, die von der Ansicht erforderlich