Verwirrung zwischen DTOs (linq2sql) und Klassenobjekte!

Question

Ich habe mit linq2sql und der Linq DTOs erfolgreich gearbeitet (den Klassen, die von linq2sql erstellt werden) ....

Ich bin verwirrt, ich habe die Aufgabe, eine alte Anwendung zu aktualisieren, und ich kann sehen, dass mein DTOs verwendet werden, wie sie sein sollte .... auf Transport Datum

Ich bin mit dem Repository-Muster so i Daten am Übergang von dem Repository in den Dienst über die linq2sql dtos ... sobald ich in der Dienstschicht bin (das ist im Grunde meine Business-Logik), dann muss ich Klassenobjekte laufen um ..

diese Klasse Objekte basicaly ein Spiegelbild sind (mehr oder weniger) der dtos - gibt es einige Änderungen an einem bestimmten Platz aber in der Regel das gleiche ..

Also immer wieder auf die Frage in der Hand! - ist dies eine gute Praxis Verwendung dtos nur Transportdaten von Repository-Service-Layer ... und einmal in der Dienstschicht (Business-Logik) Ich aber MAPPING meine dtos alle dort Klassenobjekt Gegenstücke (natürlich AutoMapper mit! !)

Meine andere Alternative ist es, weiterhin die DTOS wie Klassenobjekte zu verwenden, und geben sie um von Methode zu Methode und als Rückgabetypen usw., aber ich finde, dass das eine schlechte Praxis ist und ich halte im Kreis Runde fragen, welche Methode i gelten sollte?

Jede Hilfe wirklich zu schätzen

Dank

Answer 1

Hier ist meine Meinung: Wenn mit jeder nicht-triviale Anwendung handelt. Verwenden Sie Ihre Linq2Sql Objekte als Domain-Modell eine wirklich schlechte Idee ist. Ich sehe Linq2Sql als ORM und nichts mehr. Datenbanken (die Linq2Sql eine direkte Entsprechung hat) ist eine Normalisierung der Daten . Klassen (im OOAD Sinne) sind eine Normalisierung der Verhalten (keine Daten).

  

[diese Klasse Objekte sind im Grunde ein Spiegelbild] ...

Ich traf dies bei Anwendungen mit Linq2Sql Aufbau. Lässt realistisch sein .... die meisten Linie von Business-Anwendungen sind CRUD-Anwendungen verherrlicht. So ist es nicht in Frage, dass ein großer Prozentsatz Ihrer Anwendung Einheiten direkt auf Datenbanktabellen entspricht. Ich wollte nicht direkt an den DTO gebunden zu sein, die erzeugt wurden, aber zur gleichen Zeit wollte ich nicht dupliziert Klassen über meine Anwendung übersät.

So, hier ist meine Lösung:
I "programmiert auf eine Schnittstelle".

Nehmen wir an ich habe eine PersonDto (DTO für die Datenübertragung stehen Object) mit Eigenschaften von FirstName, LastName, Age (die direkt auf Datenbankspalten beziehen).

Ich habe einen IPerson Schnittstelle und hatte meinen PersonDto es umzusetzen.

  [Table(Name="Persons")]
  internal class PersonDto : IPerson
  {
      ....
  }

Und meine Repository-Methode würde in nehmen und abrufen IPerson in Bezug auf die Linq2Sql Klasse gegenüber.

    IPerson somePerson = _repository.Get(someGuid);
    somePerson.FirstName = "SomeName";
    _repository.Save(somePerson);

Dieser Ansatz wirklich gut für mich gearbeitet. Jedes Mal, wenn ich glaube, ich von den DTO abweichen muß, kann ich wegen der Schnittstelle so ziemlich leicht tun repräsentiert mein Objekt in Bezug auf die DTO gegenüber.

Einige allgemeine Hinweise: Bauen Sie Ihren DTO von Hand ... Ich weiß, es klingt verrückt, aber Sie werden feststellen, dass es wirklich gut mit einem von oben nach unten funktioniert, Test Driven Development-Ansatz. Ihre DTO (Linq2Sql) Objekte werden extrem leicht sein und wird außerhalb des .dbml Designer Änderungen offen sein.

Halten Sie Ihre DTO und Datacontext internen. Es gibt keinen Grund für Ihre dto öffentlich ausgesetzt werden (vorausgesetzt, dass Sie öffentliche Schnittstellen für Sie Repositories und Domain-Objekte). Dadurch wird eine logische Trennung zwischen Ihrem Domain-Modell und dem Datenzugriff erzwingen.

Setzen Sie alle Ihre Datenzugriffsschicht in einem separaten Projekt (wieder diese Trennung zu erzwingen).

Setzen Sie Ihre Interface-Deklarationen in einem separaten Projekt (dies wird sicherstellen, dass Sie in jeden zirkulären Verweis nicht ausgeführt).

Hope, das hilft ...

Answer 2

Ich hatte eigentlich eine ähnliche Frage zu diesem Thema, obwohl meine Absicht, etwas anders war. Die Empfehlung war die Linq2SQL Klassen wie die Domänenobjekte zu verwenden und profitieren Sie von Teilklassen zu nehmen, wie andere erwähnt haben. Mein Hauptanliegen kam mit der Form dieser Objekte (dh Eigenschaftsnamen) und der Zugänglichkeit der Klassenmitglieder (dh privaten v.s. beispielsweise geschützt).

Die Form der Objekte und auch die Zugänglichkeit können unter Verwendung von T4-Vorlagen adressiert werden, wo Damien Wache zusammen, um eine T4-Vorlage gelegt hat, damit Sie die Form der Klassen steuern, dass Linq2Sql für Sie erzeugen würde. Dies kann hier gesehen T4 Vorlage für Linq2SQL .

Dies ist der Ansatz, dass ich schauen werde und sehen, ob es meine Bedenken anspricht. Zusätzlich, wenn Ihr Service-Layer Schnittstellen zu Methodenargumente akzeptieren können, können Sie auch, was steuern die Service-Layer-Zugriff auf über die Schnittstelle Wrapper um Ihre Linq2SQL DTOs hat.

Hope, das hilft.

Answer 3

Dies ist eines der besten Diskussionen über das Thema, das ich je gesehen habe:

http://blog.wekeroad.com/ Blog / LinqToSql-momma-der-Knock-you-out /

Am Ende Kopplung und Zusammenhalt Entscheidungen sind situative und Sie müssen entscheiden, was am besten für Ihre Situation ist.

Wenn Sie Ihre Anwendung Auswüchsen LinqToSql, wie wird es leicht sein LinqToSql heftig zu ziehen und legen Sie eine andere ORM in seinen Platz? Das ist etwas, das Sie ernsthaft Gedanken geben.

Im Allgemeinen minimiert das Wissen Ihrer Business-Schicht über LinqToSql hat. LinqToSql sollte vollständig von Ihrer UI-Ebene ausgeblendet werden (Ihre Business-Schicht macht ein gutes Stück von diesem Schild nach oben). Es ist sehr einfach den falschen architectual Weg mit LinqToSql zu gehen und es kann sehr schwierig sein, auf dem richtigen Weg nach der Tat zu kommen.

Answer 4

Die Klassen von der linq2sql Designer erzeugt sind Teilklassen, so können Sie diese erweitern und stellen Sie Ihre Geschäftslogik direkt in sie hinein. Die Idee ist, dass Linq wird verwendet, um diese Einheiten zu beharren / rekonstruieren, so dass Sie die Art des Abbildens vermeiden Sie reden.