C# Data Layer und Dto

Question

Ich bin kürzlich einer Firma beigetreten, die typisierte Datasets als ihr 'Dto' verwendet. Ich denke, sie sind wirklich Müll und wollen es etwas moderner und benutzerfreundlicher machen. Also versuche ich, den Code zu aktualisieren, so dass die Datenschicht allgemeiner ist, d. H. Schnittstellen usw. verwendend, der andere Typ weiß nicht, was ein Dto ist, und wir haben eine leichte Uneinigkeit darüber, wie es gemacht werden sollte.

Ohne zu versuchen, Menschen zu meiner Art zu denken zu beeinflussen, würde ich gerne unparteiische Antworten von Ihnen Leuten bekommen, zu welchen Schichten das Dto anwesend sein kann. Alle Schichten; DAL, BL und Presentation oder eine kleine Untergruppe nur innerhalb dieser Schichten.

Auch, ob IList-Objekte in der DAL vorhanden sein sollen oder nicht.

Danke.

Answer 1

Es hängt wirklich von Ihrer Architektur ab.

Für den meisten Punkt sollten Sie versuchen, zu Schnittstellen zu codieren, dann ist es nicht wirklich wichtig, was Ihre Implementierung ist. Wenn Sie etwas zurückgeben, könnte es Ihre SomethingEntity oder Ihr SomethingDTO sein, aber Ihr Code ist egal, solange er die Schnittstelle implementiert.

Sie sollten eine IList/ICollection/IEnumerable über eine konkrete Sammlung oder ein Array zurückgeben.

• Properties should not return arrays
• Do not expose generic lists

Was sollten Sie zunächst versuchen, zu tun getrennt ist Ihr Code und machen es durch das Einfügen einiger Schnittstellen zwischen Schichten wie ein Endlager für Ihre Data Access Schicht lose gekoppelt. Ihr Repository gibt dann Ihre von einer Schnittstelle gekapselten Entitäten zurück. Dadurch wird Ihr Code testbarer und Sie können leichter spotten. Sobald Sie Ihre Tests an Ort und Stelle haben, können Sie beginnen, die Implementierungen mit weniger Risiko zu ändern.

Wenn Sie beginnen, Schnittstellen zu verwenden, würde ich vorschlagen, eher früher als später einen IoC wie Windsor zu integrieren. Wenn Sie es von Anfang an tun, wird es die Dinge später einfacher machen.

Answer 2

Eine Sache ist DataSets sind schlecht, Interoperabilität zu erreichen. Selbst typisierte Datasets sind nicht kompatibel, wenn es um das Schreiben von Datasets von einem Nicht-.NET-Client geht. Siehe this link. Wenn Sie die Interoperabilität erreichen wollen, dann kämpfen Sie hart für DTOs. Versuchen Sie andernfalls, Ihrem Team DTOs über einen längeren Zeitraum hinweg verständlich zu machen, da Datasets gar nicht so schlecht sind.

Auf Teil der Schnittstellen, ja sollten Sie Schnittstellen freilegen. Zum Beispiel - Wenn Sie List<T> von DAL zurückgeben, sollten Sie stattdessen IList<T> zurückgeben. Manche Leute gehen nur so weit zurück, nur IEnumerable<T>, weil alles, was Sie brauchen, ist die Fähigkeit aufzuzählen. Aber währenddessen wird es nicht astronaut architect.

In meinen Anwendungen habe ich, dass meine Code-Basis wie diese mit Codes IList<T> Rückkehr heraus statt List<T> verpestet:

//consider personCollection as IList<Person> 
(personCollection as List<Person>).ForEach(//Do Something) 

So Objekt, das ich persönlich versuchen, ein Gleichgewicht zwischen der Rückkehr Schnittstelle oder Beton zu halten. Wenn du mich fragst, was ich gerade mache, werde ich dir sagen, dass ich zurück bin List<T>. Ich bin davon beeinflusst, nicht astronaut architect zu werden.

Answer 3

Ich verwende immer DTOs, nie DataTable. Aber ich benutze sie nur, um von BL zu DL und umgekehrt zu wechseln. Meine Präsentationsschichten kennen die Business- und Service-Layer oft nur im Servicefall.

Die Vorteile kann ich sehen, DTOs zu verwenden, anstatt Datentabellen:

• leicht Refactoring
• einfache Diagramm Produktion
• cleanen lesbaren Code, vor allem in der Einheit DAL testet

Answer 4

Definitionsgemäß ist ein DTO ein Datenübertragungsobjekt, das dazu verwendet wird, Daten von einer Schicht zu einer anderen zu übertragen (darauf zu warten).

DTOs können über alle Ebenen hinweg verwendet werden und ich habe sie gut mit Webdiensten genutzt.