Design Patterns: Brauchen Sie Hilfe zu verstehen, dieses Konzept und wie es für mein Projekt gilt

Question

Die letzten paar Tage habe ich eine Menge Forschung mit dem DAL/BLL/UI-Ansatz ohne ein klares Verständnis, wie es für mich gelten wird Projekt. In der Vergangenheit habe ich die BLL weggelassen, die meine Benutzerschnittstelle direkt mit der Datenzugriffsebene (LINQtoSQL dbml) verbindet. Aber ich denke nicht, dass dies eine gute Idee ist, wo ich jetzt arbeite (oder vielleicht sogar in der Vergangenheit), weil wir viele verschiedene Anwendungen haben und ich möchte die gleiche DAL/BLL verwenden, wie sie gebaut werden.

Meine Frage ist, wie hilft die BLL mir, wenn ich in den meisten meiner Anwendungen wirklich die LinqtoSqlDataSource/GridView verwende, um eine Verbindung zu meinem Datenkontext herzustellen, um alle Aktualisierungen/Edits usw. zu erledigen , Jede neue Webanwendung wird auf einer bestimmten Ebene einzigartige Änderungen an der DAL/BLL erfordern, um die erforderlichen Daten zu erhalten, was möglicherweise Auswirkungen auf andere Apps hat, die die gleiche DAL/BLL verwenden. Ist diese Wiederverwendung der DAL/BLL der richtige Weg, oder fehlt mir etwas?

Ich denke, dass die BLL kommt, wenn ich zum Beispiel eine Sicherheitsklasse für die verschiedenen Webanwendungen erstellen muss, die gebaut werden. Aber, wenn ich die Linqtosqldatasource verwende, warum würde ich mich bemühen, es mit der BLL zu verbinden?

DAL

• LinqToSQL dbml Datacontext.
• Ändert die Verwendung von LinqToSQL, wie ich dieses Design verwenden soll?

BLL

• Sicherheit für von Unternehmen verwendet, um verschiedene Website.
• Abfrage DAL zurückgeben, was (?), Wenn LinqToSQLDatSource verwendet. Funktionen, die verschiedenen Ergebnismengen verarbeiten (mir wirklich nicht sicher bin, wie dies mit BLL funktionieren soll, tut mir leid, wenn die Frage unklar ist)

UI

• Referenz nur die BLL?

Answer 1

Die DAL und BLL sind durch einen oft subtilen, aber entscheidenden Unterschied getrennt; Geschäftslogik. Klingt moronal einfach, aber lassen Sie mich weiter erklären, weil die Unterscheidungen sehr fein sein können und dennoch die Architektur in gewaltiger Weise beeinflussen.

Mit Linq2SQL generiert das Framework sehr einfache Objekte, die jeweils einen Datensatz in einer Tabelle darstellen. Diese Objekte sind DTOs; sie sind lightwight, POCO (Plain Ol 'CLR Object) -Klassen, die nur Felder haben. Das Linq2SQL-Framework weiß, wie diese Objekte aus DB-Daten instanziiert und hydriert werden, und ähnlich kann es die in einem enthaltenen Daten in SQLDML verdauen, die den DB-Datensatz erstellt oder aktualisiert. Auf dieser Ebene sind jedoch nur wenige oder keine der Regeln bekannt, die die Beziehung zwischen Feldern verschiedener Objekte regeln.

Ihr tatsächliches Domänenmodell sollte schlauer sein; zumindest schlau genug, um zu wissen, dass eine Eigenschaft eines Order-Objekts mit dem Namen SubTotal der Summe aller ExtendedCosts aller OrderLines entsprechen sollte und ExtendedCost ebenso das Produkt aus UnitPrice und Quantity sein sollte. In vielen modernen Programmen ist Ihre Domain zumindest in diesem Umfang Teil Ihres BLL. Die Objekte, die von Linq2SQL erstellt werden, sollten das wahrscheinlich nicht alles wissen müssen, besonders wenn Sie SubTotal oder ExtendedCost nicht beibehalten. Wenn Sie sich auf die Linq2SQL-DTOs verlassen, haben Sie sich im Grunde an ein sogenanntes Anemic Domain Model gebunden, das ein bekanntes Anti-Pattern ist.Wenn das Domänenobjekt nicht mindestens intern konsistent sein kann, muss jedes Objekt, das mit dem Domänenobjekt arbeitet, vertrauenswürdig sein, um es auf diese Weise zu erhalten, sodass all diese Objekte Regeln kennen müssen, die sie nicht haben sollten. Die UI sollte über die Domäne Bescheid wissen, oder wenn Sie es bevorzugen, sollte sie eine abstrahierte Möglichkeit kennen, um die Daten aus der Domäne für Lese-Schreib-Zwecke zu erhalten (allgemein gekapselt in Objekten namens Controllers, die mit der Domain-Ebene arbeiten und/oder Linq2SQL). Die Benutzeroberfläche sollte nicht über die DB in jedem Programm von mittlerer Größe oder größer wissen müssen; Entweder können sich die Domänenobjekte mit einem Verweis auf Objekte in der DAL selbst hydrieren, oder sie werden von benutzerdefinierten Objekten in der DAL erzeugt, die Sie für die Hydration erstellen, die dann an die Steuerung gegeben werden. Das verbundene ADO-Modell und Interop mit GridViews ist bewundernswert, aber es ermöglicht keine Abstraktion. Angenommen, Sie möchten eine Web-Service-Schicht zwischen Domäne und Benutzeroberfläche einfügen, damit die Benutzeroberfläche in einer mobilen App gefunden werden kann, die mit Daten in Ihrem Warehouse funktioniert. Sie müssten Ihre Benutzeroberfläche neu erstellen, da Sie Objekte aus Linq2SQL nicht mehr direkt abrufen können. Sie erhalten sie von den Webdiensten. Wenn Sie über eine Controller-Schicht verfügen, die mit Linq2SQL kommuniziert, können Sie diese Schicht durch Controller ersetzen, die mit den Webdiensten kommunizieren. Es klingt wie ein kleiner Unterschied; Du musst immer etwas ändern. Aber jetzt verwenden Sie GENAU die gleiche Benutzeroberfläche in den Apps für Mobilgeräte und Desktops, sodass Änderungen an der Ebene THAT nicht doppelt vorgenommen werden müssen, nur weil die beiden Ebenen unterschiedliche Daten erhalten.

Answer 2

Dies ist eine großartige Frage, die ich seit einem Jahr mit unserer Katalog-App überlege. Eine spezifische Instanz für mich könnte Ihnen bei dem Muster helfen.

Ich habe eine Seite, um den Inhalt eines Einkaufswagens anzuzeigen. In den frühen Tagen war auf dieser Seite ein Raster mit den Ergebnissen einer gespeicherten SQL-Prozedur gefüllt, die die Artikel im Einkaufswagen auflistete.

Jetzt habe ich ein 'Wagen' BLL-Objekt, das eine Sammlung von 'Zeile' Objekte enthält. Das Raster ist gleich, aber die Datenquelle sind die Zeilen des Einkaufswagens.

Warum habe ich das gemacht? Anfangs nicht wegen irgendwelcher schicker Designmuster. Ich musste so viele Spezialfälle bearbeiten, die auf Feldern in jeder Zeile basierten UND ich hatte andere Stellen, an denen ich die gleichen Cart-Content-Daten anzeigen musste, es machte einfach mehr Sinn, die Objekte zu bauen. Jetzt wird ein Einkaufswagen aus einem Repository geladen und meine Seiten haben keine Ahnung, was dieses Repository tut. Zum Testen sind es hart codierte Cart-Daten.

Der Einkaufswagen verwendet dann ein Repository zum Laden der Zeilen. Jede Zeile hat eine Logik, um sich selbst zu manifestieren, ohne zu wissen, woher die Daten stammen.

Hoffentlich hilft das?