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
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.
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.
Ich gehe davon aus, dass alle drei Ebenen in derselben App existieren. In Java atleast habe ich Hibernate für den Datenzugriff verwendet und diese Datenbeans in allen Schichten verwendet. (Option B) Es ist sinnvoll, Ihre Entitäten in Ihren Layern wiederverwenden zu können.
Tags und Links architecture n-tier-architecture domain-driven-design layered
