Innovationen
Für und Wider von Datentransferobjekten
Dino Esposito
Inhalt
Fast alle Entwickler und Architekten würden die folgenden übereinstimmen. jedoch relativ verloren, die Geschäftslogikschicht (BLL) einer Softwareanwendung Definition: Die BLL ist der Teil der Softwareanwendung, die mit der Leistung von Business-Aufgaben umgeht.
Code in die BLL bezieht sich auf Daten, die versucht Modell Entitäten in der Problemdomäne – Rechnungen, Kunden, Bestellungen und Ähnliches.
Vorgänge in der BLL versucht, Geschäftsprozesse zu gestalten.
Hinter den Kulissen dieser weitgehend akzeptierte Definition liegen eine Reihe von Schlüssel Details, die nicht definiert und nicht angegeben.
Entwurfsmuster vorhanden sein, Architekten und Code Designer lose Definitionen in Blaupausen zu transformieren.
Im Allgemeinen haben BLL Entwurfsmuster ein etwas anderes Ziel.
Diese Vorgänge und Daten modellieren und häufig als Ausgangspunkt für das Entwerfen der BLL dienen.
In diesem Artikel nach eine kurze Aktualisierungsprogramm auf Verfahrensweisen und objektbasierten Muster zum Organisieren der BLL ich konzentriere auf einer Seite der das Problem – Datenübertragung Objekte –, wenn nicht effektiv auf der Ebene Architektur behandelt möglicherweise tief Auswirkungen auf die Entwicklung des Projekts.
Verfahrensinformationen Mustern für BLL
Wenn es die BLL entwerfen geht, können Sie aus der Anwendungsfälle starten, die während der Analysephase entwickelt haben.
In der Regel erhalten Sie codieren eine Methode für jede erforderliche Interaktion zwischen Benutzer und das System.
Jede Interaktion eine logische Transaktion, die alle enthält Formulare fällig Schritte – von Eingaben für die Aufgabe sammeln und Datenbankzugriff auf die Benutzeroberfläche aktualisieren.
Dieser Ansatz wird das Muster Transaktion Script (TS) genannt.
In TERMINALDIENSTE die erforderlichen Aktionen konzentrieren und nicht wirklich als gravitational Mittelpunkt der Anwendung erstellen Sie ein konzeptionelles Modell der Domäne.
Um Daten zu verschieben, können Sie keine Containerobjekte, die Sie anpassen können.
Im Bereich Microsoft .NET bedeutet dies hauptsächlich mithilfe von ADO.NET Daten Containern wie DataSets und Datentabellen.
Diese Objekte sind eine Art von Super-array-Objekt, mit einigen Suche, Indizierung und Filterfunktionen.
Darüber hinaus werden lokal Offlineszenarios aktivieren DataSets und Datentabellen über Schichten hinweg leicht serialisiert und auch beibehalten.
Das TERMINALDIENSTE-Muster nicht vorschreiben ein bestimmtes Modells für die Darstellung der Daten (und keine entweder verhindern).
Vorgänge werden in der Regel als statische Methoden in einem oder mehreren Entry-Point-Klassen gruppiert.
Alternativ können Vorgänge wie Befehle in einem Befehl Muster Ansatz implementiert werden.
Organisation der Zugriff auf Daten ist für den Entwickler links und führt normalerweise in Blöcken mit ADO.NET Code.
Das TERMINALDIENSTE-Muster ist relativ einfach einzurichten;zur gleichen Zeit es offensichtlich nicht skalieren, gut, wächst die Komplexität der Anwendung.
Im Bereich .NET verfügt über ein weiteres Muster Breite Akzeptanz im Laufe der Jahre gewonnen: die Tabelle Module-Muster.
Kurz gesagt, schlägt das Tabelle Module Muster eine Datenbank-zentrierte Vision der BLL.
Es müssen Sie eine Geschäftskomponente für jede Datenbanktabelle zu erstellen.
Die Tabellenklasse Modul genannt, Pakete die Geschäftskomponente die Daten und das Verhalten zusammen.
In der Tabelle Module-Muster wird die BLL in eine Reihe von grobe Komponenten jeweils eine gesamte Datenbanktabelle darstellen aufgeteilt.
Tabelle Module Muster eignet sich zur Verwendung von Recordset-ähnliche Datenstrukturen zum Übergeben von Daten streng von der Tabelle ausgerichtet wird, ist.
ADO.NET Datencontainer oder, besser noch, angepasste und typisierte Version von ADO.NET Container sind die natürliche Wahl.
Die Notwendigkeit einer mehr Konzeptansicht des Problemdomäne auftritt, müssen die BLL Muster, die für die Jahre im Bereich .NET gearbeitet haben einige mehr weiterentwickelt.
Architekten meist ein Entität-Beziehung Modell, das die Problemdomäne darstellt, und betrachten Sie Technologien wie LINQ-SQL und Entity Framework als konkrete Tools zur Unterstützung.
Objekt-basierten Mustern für BLL
Das Tabelle Module Muster basiert auf Objekte, aber ist nicht wirklich ein objektbasierte Muster für die Modellierung der Geschäftslogik.
Verfügt über Objekte, aber Sie sind Objekten, die Tabellen, keine Objekte, die Domäne des Problems darstellt, darstellen.
Die Geschäftslogik in einem objektorientierten Entwurf Entitäten identifiziert und all die zugelassenen und erforderlichen Interaktionen zwischen Entitäten ausdrückt.
Am Ende ist die Anwendung als eine Reihe von miteinander und interoperating Objekten angezeigt.
Der Satz von Objekten, die Zuordnung zu Entitäten sowie einige besondere Objekte durchführen von Berechnungen Formular des Domänenmodells.
(In der Entity Framework, bringen Sie das Domänenmodell mit dem Entitätsdatenmodell [EDM].)
Stehen verschiedene Stufen von Komplexität in einem Domänenmodell, die unterschiedliche Muster vorgeschlagen – normalerweise das Muster Active Datensatz oder das Domänenmodell Muster.
Ein gutes Maß dieser Komplexität ist die Lücke zwischen Entitätsmodell, das Sie Bedenken haben und das relationale Datenmodell, das Sie zum Speichern von Daten erstellen möchten.
Ein einfaches Domänenmodell ist eine in dem sich Ihre Entitäten zu Tabellen in das Datenmodell eng zuordnen.
Ein Modell nicht so einfach ist erforderlich, zuordnen zu laden und Domänenobjekte in einer relationalen Datenbank speichern.
Das Muster Active Datensatz ist ideale Wahl, wenn Sie ein einfaches Domänenmodell;Wenn Entitäten und Beziehungen unabhängig von der alle Datenbank-Konzept entwickeln vorzuziehen ist, ist das Domänenmodell Muster andernfalls die Möglichkeit zum wechseln.
Das Muster Active Datensatz ähnelt der erhalten Sie von einer LINQ-SQL-Objektmodell (und das Defaultgenerated-Modell mit Entity-Designer in Entity Framework Version 1.0).
Von einer vorhandenen Datenbank beginnen, erstellen Sie Objekte, die eine Zeile in einer Datenbanktabelle zugeordnet.
Das Objekt wird eine Eigenschaft für jede Tabellenspalte des gleichen Typs und mit den gleichen Einschränkungen verfügen.
Die ursprüngliche Formulierung des Musters Active Datensatz empfiehlt, dass jedes Objekt selbst für eigene Dauerhaftigkeit verantwortlich ist.
Dies bedeutet, dass jede Entitätsklasse Methoden enthalten soll wie speichern und laden.
Weder LINQ-SQL noch Entity Framework wird jedoch als beides delegieren Dauerhaftigkeit zu einer integrierten O-RM-Infrastruktur, die als der echte Datenzugriffsschicht fungiert, wie dargestellt im Abbildung 1.
.gif)
Abbildung 1 A Layered Architektur – das Domänen Modell Muster für die der BLL
-Dienstschicht
In Abbildung 1 wird ein logischen Abschnitt die BLL Namens als "Dienstebene"sitzen zwischen der Präsentationsschicht und der Ebene, die Dauerhaftigkeit übernimmt.
Kurz gesagt, definiert die Dienstschicht eine Schnittstelle für die Darstellungsschicht um vordefinierte Systemaktionen auszulösen.
Die Dienstschicht entkoppelt die Darstellungs- und Geschäftslogik und der Fassade für die Darstellungslogik zum Aufrufen der BLL dar.
Die Dienstschicht hat eigene Auftrag regardless of wie die Geschäftslogik intern organisiert ist.
Als Entwickler .NET sind Sie sehr vertraut mit Ereignishandlern in Web oder Windows-Formularen.
Die kanonische Button1_Click-Methode gehört zu der Darstellungsschicht und das Systemverhalten ausdrückt, nachdem der Benutzer eine bestimmte Schaltfläche geklickt hat.
Das Systemverhalten – genauer, den Sie implementieren, Anwendungsfall – einige Interaktion mit BLL Komponenten erfordern.
In der Regel müssen Sie die BLL-Komponente zu instanziieren und Skript es.
Der Code zum Skript für der Komponente kann so einfach wie beim Aufrufen des Konstruktors und vielleicht eine Methode sein.
Je öfter jedoch solcher Code ist recht umfangreiche mit Verzweigungen und müssen möglicherweise in mehrere Objekte aufrufen oder eine Antwort warten.
Die meisten Entwickler verweisen auf diesen Code als Anwendungslogik.
Daher ist die Dienstschicht der Stelle in der BLL, in dem Sie eine Anwendungslogik, Speichern während Sie unterschiedliche und separate aus Domänenlogik.
Die Domänenlogik ist keine Logik in die Klassen zu Falten, die Domäne Entitäten darstellen.
In Abbildung 1 sind die Blöcke Service Layer und Domäne Modell unterschiedliche Teile der BLL, obwohl Sie wahrscheinlich verschiedene Assemblys angehören.
Die Dienstschicht weiß das Domänenmodell und die entsprechende Assembly verweist.
Die Service Layer Assembly, stattdessen wird von der Darstellungsschicht verwiesen und der einzige Kontaktpunkt zwischen alle Darstellungsschicht darstellt (sein es Windows, Web, Silverlight oder Mobile) und der BLL.
Abbildung 2 zeigt das Diagramm der Verweise, die die verschiedenen Akteure verbinden.
Die Dienstschicht ist eine Art der Vermittler zwischen der Präsentationsschicht und der Rest der die BLL.
Daher bleibt diese sauber getrennte aber lose gekoppelte damit Sie perfekt kommunizieren können, sind.
Abbildung 2 nicht die Darstellungsschicht jeder Verweis auf die Domäne Modell Assembly enthalten.
Dies ist eine wichtige Entwurf Wahl für die meisten geschichteten Lösungen.
.gif)
Abbildung 2 Diagramm der Verweise zwischen Teilnehmer Schauspieler
Einführung in Datenobjekte übertragen
Wenn Sie eine domänenbasierte Vision der Anwendung haben, können nicht Sie helfen jedoch suchen ernsthaft in Daten Transfer-Objekte.
Keine mehrschichtige Lösung anhand von LINQ to SQL oder Entity Framework gegen Angriffe über dieses Entwurfsproblem ist.
Ist die Frage, wie Sie Daten in und aus der Darstellungsschicht verschieben möchten?
Halten Anders ausgedrückt, sollten die Darstellungsschicht einen Verweis auf die Domäne Modell Assembly?
(In einem Szenario mit Entity Framework ist die Domäne Modell Assembly nur die aus der Datei EDMX erstellte DLL.)
Im Idealfall sollte der Entwurf Abbildung 3 aussehen, wobei sind maßgefertigten Objekte verwendet, um Daten von der Präsentationsschicht an die Dienstschicht übergeben und sichern.
Diese ad-hoc-Containerobjekte werden der Name des Data-Objekte übertragen (DTOs).
.gif)
Abbildung 3 Kommunikation zwischen der Präsentationsschicht und Service Layer
Ein DTO ist nichts anderes als ein Containerklasse, die Eigenschaften verfügbar macht, aber keine Methoden.
Ein DTO ist hilfreich, wenn Sie Gruppe von Werten in ad-hoc-Strukturen zum Übergeben von Daten.
Eine Perspektive reine Entwurf sind DTOs eine Lösung tatsächlich fast perfekt.
DTOs Hilfe zur Präsentation von der Dienstschicht und das Domänenmodell weiter zu entkoppeln.
Wenn DTOs verwendet werden, die Präsentationsschicht und der Dienstschicht Datenverträge anstelle frei Klassen.
Ein Datenvertrag ist im Wesentlichen eine neutrale Darstellung der Daten, die exchange-Komponenten, die interagierende.
Der Datenvertrag beschreibt die Daten, die eine Komponente empfängt, aber es handelt sich nicht um eine Klasse systemspezifische wie eine Entität.
Am Ende des Tages ein Datenvertrag ist eine Klasse, aber es ist eher eine Hilfsklasse, die speziell für einen bestimmten Webdienstmethode erstellt.
Eine Schicht von DTOs isoliert das Domänenmodell, aus der Präsentation, was zu einer losen Kopplung und optimiert die Datenübertragung.
Weitere Vorteile von DTOs
Die Übernahme von Datenverträgen Fügt ein gutes Maß an Flexibilität der Dienstschicht und anschließend für den Entwurf der gesamten Anwendung hinzu.
Wenn DTOs verwendet werden, haben keine Änderung in die Anforderungen, die eine Verschiebung eine unterschiedliche Menge an Daten z. B. alle Auswirkungen auf die Dienstschicht oder sogar der Domäne.
Sie ändern die beteiligten DTO-Klasse durch eine neue Eigenschaft hinzufügen, aber die allgemeine Schnittstelle von der Dienstschicht beizubehalten.
Es sollte, dass eine Änderung in der Präsentation wahrscheinlich eine Änderung in einem der Verwendungsfälle bedeutet beachtet werden und daher in der Anwendungslogik.
Da die Dienstschicht die Anwendungslogik rendert, ist in diesem Kontext eine Änderung in der Dienstschnittstelle Ebene noch akzeptabel.
Jedoch in meiner Erfahrung wiederholte Änderungen an der Dienstschnittstelle Schicht können führen zu falschen Schlussfolgerung, die in die Domänenobjekte ändert – die Entitäten – möglicherweise speichern Sie weitere Änderungen in der Dienstschicht.
Ist nicht dies in well-disciplined Teams oder bei Entwicklern ein tiefes Verständnis der die Trennung von Rollen verfügen, die zwischen das Domänenmodell, die Dienstschicht und DTOs vorhanden ist.
Wie Abbildung 4 dargestellt, wenn DTOs beschäftigt sind, benötigen Sie außerdem eine Schicht DTO Adapter, ein oder mehrere Entität Objekte zu einer anderen Schnittstelle gemäß den Anwendungsfall anzupassen.
Auf diese Weise implementieren Sie tatsächlich "Adapter"Muster – eines klassischen und beliebtesten Entwurfsmuster.
Adapter-Muster konvertiert im Wesentlichen die Schnittstelle des eine Klasse in einer anderen Schnittstelle, die ein Client erwartet.
.gif)
Abbildung 4 DTO-Adapter in der BLL
Mit Bezug Abbildung 4 ist die Adapter-Schicht für das Lesen einer eingehenden Instanz der OperationRequestDTO-Klasse und für das Erstellen und Auffüllen neue Instanzen von OperationResponseDTO zuständig.
Anforderungen ändern und Änderungen in einer Ebene DTO-basierten Dienst zu erzwingen, wird Sie müssen Update die öffentlichen Daten von der DTO Vertrag und passen Sie den entsprechenden DTO-Adapter.
Die Entkopplung Vorteile von DTOs Beenden nicht hier.
Zusätzlich zu weiterhin bestehenden zum Glück Änderungen in der Präsentation können Sie die Änderungen auf die Entitäten im Domänenmodell eingeben, ohne Auswirkungen auf alle Clients möglicherweise.
Alle realistische Domänenmodell enthält Beziehungen-Kundenbestellungen sowie Order-Debitor, die eine doppelte Verknüpfung zwischen Customer- und Order-Entitäten zu bilden.
Mit DTOs können Sie das Problem der Verwaltung von Zirkelverweise während der Serialisierung von Entitätsobjekten auch umgehen.
DTOs können einen flachen Stream von Werten ausführen, die bei Bedarf über alle Grenzen hinweg einfach fein serialisieren erstellt werden.
(Ich werde zu diesem Zeitpunkt in einen Moment zurückgeben.)
Nachteile von DTOs
Im Hinblick auf reine Entwurf DTOs sind echte Vorteil, aber ist diesem theoretischen Punkt bestätigt von praktischen zu?
Als viele Punkte der Architektur-öffnen, lautet die Antwort, es abhängt.
Hunderte von Entitäten ist im Domänenmodell definitiv einen guten Grund berücksichtigt Alternativen zu einem reinen DTO-basierten Ansatz.
Fügen Sie in großen Projekten mit so vielen Entitäten DTOs ein bemerkenswert Maß an Komplexität (zusätzlichen) und zu tun.
In Short, eine reine 100 % DTO Lösung ist häufig nur eine 100 % mühsam Projektmappe.
Während normalerweise die Komplexität von DTOs einer Projektmappe hinzugefügt mit die Kardinalität des Domänenmodells gemessen wird, können die Real-Anzahl der erforderlichen DTOs mehr zuverlässig bestimmt die Anwendungsfälle und die Implementierung der Dienstschicht ansehen sein.
Darin, dass eine gute Formel für die Schätzung wie viele DTOs Sie müssen die Anzahl der Methoden in der Dienstschicht betrachten.
Die reelle Zahl kann sein, kleiner, wenn Sie über mehrere Webdienstaufrufe Layer einige DTOs wiederverwenden können, oder höher, wenn Ihre DTOs einige Daten mithilfe von komplexe Typen gruppieren.
Zusammenfassend ist das einzige Argument gegen mithilfe von DTOs die zusätzliche Arbeit, die zum Schreiben und verwalten die Anzahl der resultierenden DTO-Klassen erforderlich.
Es ist nicht, jedoch eine einfache von einem Programmierer Bequemlichkeit und unerheblich.
In großen Projekten Kosten Präsentation von der Dienstschicht entkoppeln Sie Hunderte von neuen Klassen.
Es sollte auch beachtet werden, dass ein DTO nicht einfach eine lightweight Kopie jede Entität ist möglicherweise.
Angenommen, zwei verschiedene Anwendungsfällen müssen Sie eine Auflistung von Bestellungen zurückzugeben – sagen, GetOrdersByCountry und GetOrdersByCustomer.
Sehr wahrscheinlich die Informationen in "Order" Einfügenunterscheidet.
Wahrscheinlich benötigen Sie weitere (oder weniger) Details in GetOrdersByCustomer als in GetOrdersByCountry.
Dies bedeutet, dass unterschiedliche DTOs erforderlich sind.
Aus diesem Grund Hunderte von Entitäten sind sicherlich eine schnelle Messung der Komplexität, aber die reelle Zahl von DTOs können nur durch Betrachten Anwendungsfälle bestimmt werden.
Wenn DTOs nicht immer optimal sind, wäre was eine sinnvolle Alternative Methode?
Die einzige alternative zur Verwendung von DTOs besteht darin, die Domäne Modell Assembly aus in der Darstellungsschicht verweisen.
Auf diese Weise richten Sie jedoch eine enge Kopplung zwischen den Ebenen.
Und eng gekoppelte Ebenen möglicherweise ein Problem schlimmer.
Entitäten direkt verweisen
Eine erste, nicht so offensichtliche Bedingung So aktivieren Sie die Verknüpfung von Entitäten direkt aus der Darstellungsschicht ist, dass es die Darstellungsschicht Daten im Format der Entitätsobjekte empfangen akzeptabel ist.
Die Präsentation benötigt manchmal Daten in einer bestimmten Weise formatiert.
Ein DTO Adapter Layer zu nur Massage Daten gemäß dem Client vorhanden ist.
Wenn Sie jedoch nicht DTOs verwenden, muss die Last richtig Formatieren von Daten auf der Präsentationsebene verschoben werden.
Tatsächlich ist die falsche Stelle in der Format-Daten für Benutzer Schnittstelle Zwecke das Domänenmodell selbst.
Realistisch, können Sie ohne DTOs tun, nur, wenn die Präsentationsschicht und der Dienstschicht in demselben Prozess Zusammenlegung sind.
In diesem Fall können Sie problemlos die Entität-Assembly in beide Ebenen ohne Umgang mit thorny Problemen wie z. B. Remoting und Daten Serialisierung verweisen.
Diese Überlegung führt zu einem anderen gute Frage: Wo sollten Sie die Dienstschicht anpassen?
Wenn der Client einer Seite ist, ist die Dienstschicht vorzugsweise lokal auf dem Webserver, der die Seite hostet.
In ASP.NET Anwendungen die Darstellungsschicht ist, alle im Code - behind-Klassen und befinden sich nebeneinander mit Dienstschicht in derselben Anwendungsdomäne.
In einem solchen Szenario jede Kommunikation zwischen der Präsentationsschicht und der Dienstschicht erfolgt in-Process und Objekte können mit keine weiteren Sorge freigegeben werden.
ASP.NET Anwendungen sind ein guter Szenario können Sie eine Lösung versuchen, die die zusätzliche Schicht von DTOs nicht verwendet.
Technology-Wise, können Sie die Dienstschicht über einfache .NET Objekte oder über lokale Windows Communication Foundation (WCF) Dienste implementieren.
Wenn die Anwendung erfolgreich ist, können Sie problemlos Skalierbarkeit erhöhen, indem die Dienstschicht auf einem Server separate Anwendung verschieben.
Ist der Client eine Desktopanwendung ist dann die Dienstschicht i. d. r. in einer anderen Ebene bereitgestellt und Remote über den Client zugegriffen.
Sofern der Client und dem Remoteserver die gleiche .NET Plattform verwenden, können Sie Remoting Techniken (oder besser, WCF-Dienste) zum Implementieren von Kommunikation und systemeigene Entitätsobjekte weiterhin an beiden Enden verwenden.
Die WCF-Infrastruktur wird kümmern Marshallen von Daten über Schichten hinweg und in Kopien des systemeigenen Entitäten Pumpe.
In diesem Fall können Sie auch eine Architektur anordnen, die nicht DTOs verwendet.
Dinge ändern erheblich, wenn die Client und Server-Plattformen nicht kompatibel sind.
In diesem Fall müssen Sie keine Wahrscheinlichkeit die systemeigenen Objekte verknüpfen und diese vom Client; aufrufenNachfolgend, Sie sind in einem reinen dienstorientierte Szenario und mithilfe von DTOs ist die einzige Möglichkeit.
Die Mitte-Methode
DTOs sind den Betreff der eine wichtige Entwurfsentscheidung, die die Implementierung der Kommunikation zwischen der Präsentation und dem Back-End des Systems auswirkt.
Wenn Sie DTOs einsetzen, behalten Sie das System, lose gekoppelten und gegen eine Vielzahl von Clients geöffnet.
DTOs sind die ideale Wahl, wenn Sie sich leisten können.
DTOs hinzufügen eine erhebliche Programmierung Aufwand an realen System.
Dies bedeutet nicht, dass DTOs nicht verwendet werden sollte, aber Sie führen zu einer Verbreitung von Klassen, die eigentlich ein Albtraum Wartung in Projekten mit ein paar Hundert Entitätsobjekte und sogar noch mehr Anwendungsfälle prefigure können.
Wenn Sie auf die gleiche Zeit einen Anbieter und Consumer von der Dienstschicht, und vollständige Kontrolle über die Präsentation haben Sie möglicherweise Vorteile in verweisen auf die Entität Modell Assembly aus der Präsentation.
Auf diese Weise werden alle Methoden in der Dienstschicht mit Entitäten als die Datenverträge deren Signaturen zulässig.
Die Auswirkungen auf Entwurf und Codierung sind klar ziemlich weichere.
Ob Sie DTOs oder nicht zu verwenden ist kein leicht zu verallgemeinern.
Um effektiv zu sein, sollten die endgültige Entscheidung immer vorgenommen werden die Besonderheiten des Projekts betrachten.
Am Ende ist ein gemischter Ansatz wahrscheinlich, was Sie in den meisten Fällen durchführen müssen.
Neigen dazu ich persönlich zu Entitäten wie möglich verwenden.
Dies geschieht nicht, weil ich gegen Reinheit und sauberen Entwurf, jedoch für eine einfachere Frage des Pragmatism.
Mit ein Entitätsmodell, die Konten für nur 10 Entitäten und ein paar Anwendungsfälle, verwenden Sie DTOs ganz über keine bedeutendes Problem darstellen.
Und Sie erhalten praktische Entwurf und Niedrig Kopplung.
Jedoch mit Hunderten von Entitäten und verwenden Fällen die reelle Zahl von Klassen zu schreiben, Verwalten und Test ominously die Reihenfolge der Tausende nähert.
Alle möglichen Reduzierung der Komplexität, die Anforderungen erfüllt ist mehr als Willkommen.
Als Architekt sollten Sie jedoch immer sein auf die Warnung zum Erkennen der Anzeichen, dass der Abstand zwischen das Entitätsmodell und was die Präsentation erwartet bedeutende oder zur Deckung unmöglich ist.
In diesem Fall sollten Sie die Route sicherere (und Bereinigung) DTOs ergreifen.
Gemischte Ansatz
Überlappende heutigen Anwendungen reservieren einen Abschnitt der BLL dem Dienst-Layer.
Die Dienstschicht (auch als der Anwendungsebene bezeichnet) enthält die Anwendungslogik;d. h., die Geschäftsregeln und Prozeduren, die bestimmte auf die Anwendung jedoch nicht auf die Domäne.
Ein System mit mehreren front-Ends ein einzelnes Teils Domänenlogik über Entitätsklassen macht, aber dann müssen jedes front-End eine zusätzliche Geschäftsschicht spezifisch für die Anwendungsfälle unterstützt wird.
Dies ist, was als Layer Service (oder Anwendung) bezeichnet wird.
Ausgelöst von der Benutzeroberfläche, Skripts die Anwendungslogik, die Entitäten und Dienste in der Geschäftslogik.
In der Dienstschicht Sie implementieren die Anwendungsfälle und offen legen jede Abfolge der Schritte über eine grobe Methode für die Präsentation aufrufen.
Im Entwurf der Dienstschicht sollten Sie einige best Practices anwenden, Dienstorientierung nutzen und Freigeben von Datenverträgen anstelle von Entitäten.
Dieser Ansatz in der Theorie ideal ist, Konflikt oft mit der realen Welt, wie es zu viel Aufwand in Projekten mit Hunderten von Entitäten und Anwendungsfälle hinzufügen endet.
Wie sich herausstellt, dass ein gemischter Ansatz, der Daten verwendet Verträge nur bei Verwendung von Klassen nicht möglich ist, ist oft mehr akzeptable Lösung.
Aber als Architekt, Sie müssen nicht diese Entscheidung leicht.
Ein guter Entwurfsregeln verletzen ist zulässig, solange Sie wissen, was Sie tun.
Dino Esposito ist Architekt bei IDesign und Mitautor von Microsoft.NET: Entwickeln Anwendungen für die Enterprise- (Microsoft Press, 2008).
Dino arbeitet in Italien und ist ein weltweit gefragter Referent bei Branchenveranstaltungen.
Sie können seinen Blog unter weblogs.asp.net/despos beitreten.