Datenübertragung Objekte in der Business-Logik-Schicht Wie Design

Question

DTO

Ich baue eine Web-Anwendung ich für viele Benutzer skalieren möchte. Außerdem muss ich Funktionalität an vertrauenswürdige Dritte über Web Services verfügbar machen.

I LLBLGen bin mit der Datenzugriffsschicht (unter Verwendung von SQL Server 2008) zu generieren. Das Ziel ist es, eine Business-Logik-Schicht aufzubauen, die den Web-App von den Details der DAL und natürlich abschirmt, eine zusätzliche Ebene der Validierung über die DAL zur Verfügung zu stellen. Auch soweit ich jetzt sagen kann, wird der Web Service im Wesentlichen eine dünne Hülle über den BLL sein.

Die DAL, hat natürlich seinen eigenen Satz von Entitätsobjekten zum Beispiel CustomerEntity, ProductEntity, und so weiter. Aber ich will nicht die Präsentationsschicht Zugriff auf diese Objekte direkt haben, wie sie auf die DAL DAL spezifischen Methoden und die Montage ist spezifisch enthalten und so weiter. So ist die Idee Data Transfer Objects (DTO) zu erstellen. Die Idee ist, dass diese wird im Wesentlichen nur alte C # /. NET-Objekte, die alle Felder von, sagen wir, ein CustomerEntity, die tatsächlich die Datenbanktabelle Kunden, aber keiner von den anderen Sachen sind, außer vielleicht einigen IsChanged / IsDirty Eigenschaften. So gäbe es CustomerDTO, ProductDTO usw. Ich nehme diese von einer Basis DTO-Klasse erben würde. Ich glaube, dass ich diese mit einem gewissen Vorlage für LLBLGen erzeugen kann, aber ich bin nicht sicher, es noch nicht.

So ist die Idee, dass die BLL seine Funktionalität Objekte durch die Annahme und Rückgabe dieser DTO aussetzen wird. Ich denke, die Web-Service behandelt diese Objekte zu XML für die Dritte konvertieren Sie es, viele können nicht .NET werden (auch werden einige Dinge Skript aufrufbar von AJAX fordert die Web App sein, mit JSON).

Ich bin nicht sicher, den besten Weg, dies zu entwerfen und zu genau, wie vorwärts zu gehen. Hier sind einige Fragen:

1) Wie soll dies die Kunden ausgesetzt werden (die Präsentationsschicht und an den Web-Service-Code)

Ich dachte, dass es eine öffentliche Klasse sein würde, die diese Methoden haben, würde jeder Anruf eine atomare Operation sein werden:

InsertDTO, UpdateDTO, DeleteDTO, GetProducts, GetProductByCustomer und so weiter ...

Dann würden die Kunden nur diese Methoden aufrufen und in die entsprechenden Argumente übergeben, in der Regel ein DTO.

Ist das ein guter, praktikable Ansatz?

2) Was von diesen Methoden zurückzukehren? Offensichtlich ist die Get / Fetch Art von Methoden DTO zurückzukehren. Aber was Einsätze? Ein Teil der Unterschrift könnte sein:

InsertDTO(DTO dto)

Wenn jedoch Einfügen was soll zurückgegeben werden? Ich möchte benachrichtigt von Fehlern werden. Allerdings benutze ich selbstinkrementierende Primärschlüssel für einige Tabellen (jedoch ein paar Tische haben natürlichen Schlüssel, besonders viele-zu-viele sind).

Eine Option Ich dachte war ein Ergebnis Klasse:

class Result
{
    public Exception Error {get; set;}
    public DTO AffectedObject {get; set;}
}

Also, an einem Einsatz würde der DTO seine get-ID (wie CustomerDTO.CustomerID) Eigenschaft festgelegt und dann in diesem Ergebnis Objekt setzen. Der Kunde wird wissen, ob es ein Fehler, wenn Result.Error! = Null und dann würde es die ID aus der Result.AffectedObject Eigenschaft kennen.

Ist das ein guter Ansatz? Ein Problem ist, dass es scheint, wie es eine Menge Daten zurück vorbei und her das ist überflüssig (wenn es nur die ID). Ich glaube nicht, eine „int NewID“ Eigenschaft hinzugefügt wäre sauber, weil einige Einsätze keinen selbstinkrementierende Schlüssel wie das haben. Ein weiteres Problem ist, dass ich glaube nicht, Web Service diese gut behandeln würde? Ich glaube, sie würde nur die Basis DTO für affectedObject im Ergebnisklasse zurückzukehren, anstatt der abgeleiteten DTO. Ich glaube, ich könnte dieses Problem lösen, indem eine Menge der verschiedenen Arten von Ergebnisobjekten mit (vielleicht von einer Basis Ergebnis abgeleitet und die Eigenschaft Fehler erben), aber das scheint nicht sehr sauber.

In Ordnung, ich hoffe, dass dies nicht zu wortreich, aber ich mag klar sein.

Answer 1

1: Das ist ein ziemlich Standard-Ansatz, der sich gut für eine „Repository“ Implementierung für die beste Einheit testbare Ansatz verleiht

.

2: Ausnahmen (die als „Fehler“ auf der WCF-Grenze deklariert werden sollen, btw) automatisch erhalten angehoben. Sie brauchen nicht, dass direkt zu handhaben. Für Daten - es gibt drei gemeinsame Ansätze:

• Verwendung ref auf dem Vertrag (nicht sehr hübsch)
• Rückkehr des (aktualisiert) Objekt - das heißt public DTO SomeOperation(DTO item);
• Rückkehr nur die aktualisierte Identitätsinformationen (Primärschlüssel / Zeitstempel / etc)

Eine Sache, über all dies ist, dass es nicht eine andere Art pro Betrieb erforderlich macht (Kontrast Ihre Result Klasse, die pro DTO dupliziert werden müßte).

Answer 2

Q1: Sie können denken Sie an Ihre WCF Data Contract Verbundtypen als DTOs dieses Problem zu lösen. Auf diese Weise Ihre UI-Ebene hat nur Zugriff auf die Datamember Eigenschaften des Datacontract. Ihre atomaren Operationen würden die Methoden, die von WCF-Schnittstelle ausgesetzt sein.

Q2:. Konfigurieren Sie Ihre Verträge Antwortdaten einen neuen benutzerdefinierten Typ mit dem Primärschlüssel usw. zurückzukehren ... WCF kann auch auf Blase Ausnahmen zurück in die Benutzeroberfläche konfiguriert werden