n-tier-architecture

Wenn Sie einen Layered -Ansatz verwenden, was bedeutet, dass alle Layer (im Wesentlichen) im selben Prozessbereich ausgeführt werden und daher kein Marshalling / Serialisierung erfolgt, würde ich Ansatz B verwenden. Erstellen ein separates Modul für Ihre Entitäten, von dem alle Aspekte Ihres Programms abhängig sind, und mit diesem verbunden werden.

Wenn Sie jedoch einen abgestuften Ansatz verwenden, wie es Ihr Titel vermuten lässt, was bedeutet, dass Prozess- und / oder Netzwerkgrenzen überschritten werden, würde ich vorschlagen, dass Sie mit Ansatz C fortfahren Wenn Sie Instanzen nicht wirklich weitergeben, übergeben Sie Kopien, so dass alle Vorteile, die Sie beim Koppeln mit dem gleichen Objekt erhalten, wie beispielsweise beobachtbare Optionen für einen MVC-Ansatz, verloren gehen. Es ist besser, Daten-APIs auf jeder Ebene zu definieren, als zu versuchen, überall die gleiche Klasse zu verwenden.

Wie übergibt man Daten an Ebenen in einer n-Tier-Anwendung? Ich habe 3 verschiedene Methoden festgelegt.

A) generische .net-Objekte Generische Datentabellen, Hashtables, generische Datasets, Strings, Ints etc ... Verwenden Sie dann die Datensätze, um Ihre Geschäftsobjekte zu füllen, die an die UI-Ebene gesendet werden.

Alternativtext http://img11.imageshack.us/img11/460/generic.png

Ссылка

Pro - Keine zusätzlichen Ebenen erforderlich Con - Arbeiten mit generischen Datasets und Tabellen in der Business-Schicht

B) Verwenden eines Entity-Layers, auf den die anderen Layer verweisen würden. Diese Ebene enthält entweder stark typisierte Datasets oder einfache alte C-Objekte. Die Objekte wären meist Containerdaten und sehr wenig Logik. Dies wären die gleichen Objekte, die an die UI-Ebene gesendet werden.

Alternativtext http://img8.imageshack.us/img8/6454/entities.png

Ссылка

Pro - arbeitet mit den gleichen Klassen in allen Ebenen Con - Hinzufügen eines Verweises auf entities.dll zu allen Layern

C) Verwenden Sie Datentransferobjekte (nur Conatiner-Objekte), die in der DataAccess-Schicht definiert sind. Verwenden Sie dann diese Objekte zum Füllen von Geschäftsobjekten, die an die UI-Ebene gesendet werden.

Alternativtext http://img43.imageshack.us/img43/1236/transferp.png

Ссылка

Pro - Die Business-Schicht müsste nicht mit generischen Klassen arbeiten Con - arbeitet mit zwei Arten von Objekten und Sie müssten die Geschäftsobjekte mit den Transferobjekten hydratisieren

Wir hatten eine Diskussion bei der Arbeit und wollten sehen, was die Community dachte. Ich habe auch einen Link zum Dabbleboard hinzugefügt. bitte kopieren und erstellen statt editieren.
Danke

Ich mag Option C, aber es gibt mir auch aus zwei Gründen eine Pause:

1. Ich muss das Wissen darüber verbreiten, was die Eigentümer an zu vielen Orten sind.
2. DTOs müssen serialisierbar sein, was nicht schlimm ist, aber immer noch eine Überlegung wert ist.

Gute Frage - wie immer muss die Antwort lauten: "Es kommt darauf an".

Bei der Art der Anwendung, und ob Geschäftsobjekte (Entitäten) wirklich benötigt werden, im Gegensatz zu Transferobjekten (d. h. verdummten Geschäftsobjekten, die eher Datenbankeinheiten entsprechen).

Traditionell hätte ich argumentiert, dass Sie immer nur aus Performancegründen generische Datensätze (oder Datentabellen) benötigen. Wann immer es notwendig ist, mit größeren Mengen zu arbeiten, anzuzeigen oder zu manipulieren, ist die traditionelle strikte OO-Methode zum Instanziieren einer großen Anzahl von Geschäftsobjekten fehlgeschlagen.

Seit ich jedoch mit Linq zu SQL arbeite, haben sich meine Paradigmen geändert. Dies ist nicht mehr notwendig, da das Linq-Modell alles sein kann - Geschäftsobjekte, Transferobjekte und generische Datasets. Ich habe noch nicht untersucht, wie gut das in wirklich großen Anwendungen funktioniert und ob es notwendig ist, Front-End-Code vom Linq-Modell zu isolieren. Ich habe mit Kollegen darüber gesprochen, ohne wirklich eine Antwort zu finden.