Implementierung der Designlogik

Philosophien des Implementierungsansatzes

Wasserfall-Ansatz

Beim Wasserfall-Ansatz zur Implementierung einer Anwendung muss sich ein Designer mit einem oder mehreren Vertretern der Endbenutzerorganisation beraten und alle Spezifikationen der Anwendung aufschreiben. Typischerweise werden Spezifikationen in einer Reihe von funktionalen Dokumenten oder Anwendungsfällen bereitgestellt, die so geschrieben sind, dass der Endbenutzer die Dokumente leicht lesen und verstehen kann.

Der Endbenutzer signiert diese Dokumente, und die Dokumente werden dann vom technischen Designteam gesammelt, das die Anwendung entwirft und verschiedene Artefakte wie Klassenmodelldiagramme, Zustandsdiagramme, Aktivitätsdiagramme und Datenmodelle erstellt. Das Ziel dieser Phase ist es, alles so detailliert zu schreiben, dass ein Entwickler keine Probleme haben wird, den notwendigen Code zu erstellen. Es gibt eine formelle Übergabe des Designs an das Entwicklungsteam und an das Testteam. Nach der Lieferung beginnt das Entwicklungsteam mit der Codierung und das Testteam verwendet das technische Design in Kombination mit den Anwendungsfällen, um Testfälle und Testszenarien zu erstellen.

Nachdem das Entwicklungsteam mit der Codierung fertig ist, wird der Code an das Testteam übergeben. Das Testteam führt die von ihm entworfenen Tests anhand der Anforderungen und des detaillierten Designs durch. Alle Probleme werden vom Entwicklungsteam behoben. Sobald der Test- und Korrekturprozess abgeschlossen ist, wird die Anwendung an den Endbenutzer zum Abnahmetest geliefert. Der Endbenutzer führt eine abschließende Prüfung durch, um zu sehen, ob die Anwendung die anfänglichen Anforderungen erfüllt. Wenn genehmigt, genehmigt er das fertige Produkt und das Projekt ist abgeschlossen. Nachdem das Entwicklungsteam mit der Codierung fertig ist, wird der Code an das Testteam übergeben.

Das Testteam führt die von ihm entworfenen Tests anhand der Anforderungen und des detaillierten Designs durch. Alle Probleme werden vom Entwicklungsteam behoben. Sobald der Test- und Korrekturprozess abgeschlossen ist, wird die Anwendung an den Endbenutzer zum Abnahmetest geliefert. Der Endbenutzer führt eine abschließende Prüfung durch, um zu sehen, ob die Anwendung die anfänglichen Anforderungen erfüllt. Wenn genehmigt, genehmigt er das fertige Produkt und das Projekt ist abgeschlossen. Nachdem das Entwicklungsteam mit der Codierung fertig ist, wird der Code an das Testteam übergeben. Das Testteam führt die von ihm entworfenen Tests anhand der Anforderungen und des detaillierten Designs durch.

 Alle Probleme werden vom Entwicklungsteam behoben. Sobald der Test- und Korrekturprozess abgeschlossen ist, wird die Anwendung an den Endbenutzer zum Abnahmetest geliefert. Der Endbenutzer führt eine abschließende Prüfung durch, um zu sehen, ob die Anwendung die anfänglichen Anforderungen erfüllt. Wenn genehmigt, genehmigt er das fertige Produkt und das Projekt ist abgeschlossen.

Der Endbenutzer führt eine abschließende Prüfung durch, um zu sehen, ob die Anwendung die anfänglichen Anforderungen erfüllt. Wenn genehmigt, genehmigt er das fertige Produkt und das Projekt ist abgeschlossen. Der Endbenutzer führt eine abschließende Prüfung durch, um zu sehen, ob die Anwendung die anfänglichen Anforderungen erfüllt. Wenn genehmigt, genehmigt er das fertige Produkt und das Projekt ist abgeschlossen.

Ein Projekt kann mehr oder weniger Phasen haben, wenn der Wasserfallansatz verwendet wird, aber das Hauptmerkmal ist ein sehr formaler Beginn und ein Ende jeder Phase mit sehr formalen Ergebnissen.

Der Vorteil des Wasserfallansatzes liegt darin, dass die Verantwortung des für die jeweilige Phase verantwortlichen Teams größer ist. Es ist klar, was sie liefern müssen, wann sie es liefern müssen und an wen sie es liefern müssen. Oft muss das Entwicklungsteam nicht mit dem Benutzer interagieren. Dies kann sehr nützlich sein, wenn die Entwicklung in ein anderes Land ausgelagert wird.

Der Hauptnachteil des Wasserfallansatzes besteht darin, dass in einer Umgebung, in der alles sehr formal organisiert ist, die Flexibilität, auf Änderungen zu reagieren, abnimmt. Auch ein Umzug muss organisiert werden. Nur sehr wenige Unternehmen scheinen dies effektiv zu tun, was oft zu einem erheblichen Anstieg der Gemeinkosten führt. Um die Kosten eines Projekts im Griff zu behalten, verschieben einige Unternehmen Änderungen an Anforderungen sogar bis zur Bereitstellung der ersten Anwendung, wodurch sie effektiv eine Anwendung liefern, die die Anforderungen des Endbenutzers nicht erfüllt.

agile Entwicklung

Viele langjährige Softwareentwicklungsprojekte gingen über das Budget hinaus und lieferten das Produkt nicht rechtzeitig. Die Prämisse der agilen Softwareentwicklungsphilosophie besteht darin, das Risiko zu minimieren, indem Software in kurzen Zeitfenstern, sogenannten Iterationen, entwickelt wird, die normalerweise eine bis vier Wochen dauern. Jede Iteration ist wie ein eigenes Miniatur-Softwareprojekt und umfasst alle Aufgaben, die für die Veröffentlichung des Inkrements neuer Funktionen erforderlich sind: Planung, Anforderungsanalyse, Design, Codierung, Test und Dokumentation. Während eine Iteration möglicherweise nicht genügend Funktionalität hinzufügt, um eine Produktfreigabe zu rechtfertigen, zielt ein agiles Softwareprojekt darauf ab, am Ende jeder Iteration neue Software veröffentlichen zu können. Am Ende jeder Iteration bewertet das Team die Prioritäten des Projekts neu.

Das Ziel der agilen Softwareentwicklung ist es, die Kundenzufriedenheit durch die schnelle und kontinuierliche Bereitstellung nützlicher Software zu erreichen; immer mit dem Ziel, das zu bauen, was der Kunde braucht; verspätete Änderungen der Anforderungen begrüßen, nicht ablehnen; sich regelmäßig an sich ändernde Umstände anpassen; eine enge und tägliche Zusammenarbeit zwischen Unternehmern und Entwicklern zu haben, in der das persönliche Gespräch die beste Form der Kommunikation ist.

Der Hauptvorteil der agilen Softwareentwicklung ist die Flexibilität im Umgang mit Änderungen, immer mit dem Ziel, die Geschäftsanforderungen zu erfüllen. Die Kehrseite ist natürlich eine Zunahme der Komplexität bei der Verwaltung des Umfangs, der Planung und der Budgetierung. Ein weiteres häufiges Risiko ist die eingeschränkte Aufmerksamkeit für die (technische) Dokumentation.

Inkrementelle Entwicklung

Inkrementelle Softwareentwicklung ist eine Mischung aus agiler und Wasserfallentwicklung. Eine Anwendung wird inkrementell entworfen, implementiert und getestet, sodass jedes Inkrement an den Endbenutzer geliefert werden kann. Das Projekt ist erst abgeschlossen, wenn das letzte Inkrement abgeschlossen ist. Es zielt darauf ab, die Kaskade zu verkürzen, indem Zwischeninkremente definiert und einige der Vorteile der agilen Entwicklung genutzt werden. Basierend auf dem Feedback zu einem vorherigen Inkrement können bei der Lieferung des nächsten Inkrements Anpassungen vorgenommen werden. Das nächste Inkrement kann aus neuem Code sowie Modifikationen an zuvor bereitgestelltem Code bestehen.

Der Vorteil ist, dass die Formalitäten bestehen bleiben, aber das Änderungsmanagement einfacher wird. Die Kosten für das mehrmalige Testen und Bereitstellen einer Anwendung sind höher als für die einmalige Durchführung.

Programmablaufsteuerung

Die Wahl eines Ansatzes zur Programmablaufsteuerung ist eine sehr architektonische Aufgabe. Das Ziel ist es, einen Entwurf Ihrer Anwendung zu erstellen, in dem, sobald Sie mit dem Hinzufügen von Funktionen und Code beginnen, alles seinen eigenen Platz zu haben scheint. Wenn Sie jemals hochwertigen Code überprüft oder geschrieben haben, verstehen Sie dieses Prinzip.

Veranstaltercode

Der erste Schritt beim Entwerfen des Programmablaufs besteht darin, den Code zu organisieren, indem eine Reihe von Regeln aufgestellt werden, die dabei helfen, einen Entwurf oder eine Gliederung der Anwendung zu erstellen. Wartung, Debugging und Fehlerbehebung werden einfacher, da sich der Code an einem logischen Ort befindet. Nachdem Sie die Grundlagen geschaffen haben, können Sie einen Ansatz zur Implementierung der Logik Ihrer Anwendung auswählen.

Entwurfsmuster sollten eine wichtige Rolle bei der Gestaltung der Programmablaufsteuerung spielen. Im Laufe der Jahre wurde viel Code geschrieben und viele Lösungen für wiederkehrende Probleme entworfen. Diese Lösungen sind in Entwurfsmustern angeordnet. Das Anwenden eines Entwurfsmusters auf ein allgemeines Softwaredesignproblem hilft Ihnen, Lösungen zu erstellen, die leicht erkennbar sind und von Ihren Kollegen implementiert werden können. Einzigartige Probleme erfordern immer noch einzigartige Lösungen, aber Sie können Entwurfsmuster verwenden, um Sie bei der Lösung zu unterstützen.

Erstellen des Projekts

Lagen

Der erste Schritt besteht darin, logische Schichten zu betrachten. Beachten Sie, dass Ebenen nicht dasselbe sind wie Ebenen, oft verwechselt oder sogar als gleich angesehen werden.

Schichten gegen Schichten

Bei Layern geht es darum, Grenzen in Ihrem Code zu erstellen. Die oberste Ebene kann Verweise auf Code in darunter liegenden Ebenen haben, aber eine Ebene kann niemals eine Referenz auf Code in einer darüber liegenden Ebene haben. Tiers beziehen sich auf die physische Verteilung von Tiers auf mehrere Computer. Beispielsweise ist in einer dreischichtigen Anwendung die Benutzeroberfläche für die Ausführung auf einem Desktop-Computer konzipiert, die Anwendungslogik für die Ausführung auf einem Anwendungsserver und die Datenbank für dedizierte Daten und den jeweiligen Code auf einem Datenbankserver Schicht kann aus mehreren Schichten bestehen.

Abbildung 8-1: Grundlegende dreistufige Organisation

Ebenen beziehen sich auf Abstraktionsebenen. Die in Abbildung 8-1 gezeigten Schichten gelten für die meisten Anwendungen. Diese Ebenen werden auch als die drei Hauptschichten bezeichnet und können verschiedene andere Namen haben. In der Regel kann Code in der Präsentationsschicht Dienste in der Anwendungslogikschicht aufrufen, aber die Anwendungslogikschicht darf die Methode in der Präsentationsschicht nicht aufrufen. Die Präsentationsschicht sollte die Datenzugriffsschicht niemals direkt aufrufen, da dies die Verantwortlichkeiten umgehen würde, die von der Anwendungslogikschicht implementiert werden. Die Datenzugriffsschicht sollte niemals die Anwendungslogikschicht aufrufen.

Ebenen sind nur eine Abstraktion, und die wahrscheinlich einfachste Möglichkeit, Ebenen zu implementieren, besteht darin, Ordner in Ihrem Projekt zu erstellen und dem entsprechenden Ordner Code hinzuzufügen. Ein sinnvollerer Ansatz wäre es, jede Ebene in einem separaten Projekt zu platzieren und so separate Baugruppen zu erstellen. Wenn Sie Ihre Anwendungslogik in eine Bibliotheksassembly einfügen, haben Sie den Vorteil, dass Sie mithilfe von Microsoft Visual Studio oder NUnit Komponententests erstellen können, um die Logik zu testen. Es schafft auch Flexibilität bei der Auswahl, wo jede Ebene bereitgestellt werden soll.

Physikalische Schichten

In einer Unternehmensanwendung würden Sie mehrere Clients für dieselbe Logik erwarten. Was eine Anwendung tatsächlich zu einer Unternehmensanwendung macht, ist, dass sie in drei Schichten bereitgestellt wird: Client, Anwendungsserver und Datenbankserver. Die von der Vertriebsabteilung Ihres Unternehmens erstellte Microsoft Office Access-Anwendung ist zwar sehr wichtig für die Vertriebsabteilung, aber keine Unternehmensanwendung.

Beachten Sie, dass Anwendungslogik und Datenzugriffsschichten häufig zusammen auf dem Anwendungsserver bereitgestellt werden. Ein Teil des Entwurfs des Projekts besteht darin, zu entscheiden, ob der Zugriff auf den Anwendungsserver über Remote-.NET- oder Webdienste erfolgen soll. Wofür Sie sich auch entscheiden, Sie fügen Code hinzu, um einfach auf Remotedienste in der Präsentationsschicht zuzugreifen. Wenn Sie Webdienste für den Zugriff auf Dienste auf Ihrem Anwendungsserver verwenden, übernimmt Visual Studio .NET die Arbeit für Sie und generiert den Proxy-Code, wodurch automatisch eine Implementierung des Remote-Proxy-Musters bereitgestellt wird.

Hinzufügen von Mustern zu Ebenen

Die drei grundlegenden Ebenen bieten einen allgemeinen Überblick. Lassen Sie uns einige strukturelle Muster hinzufügen, um eine robuste Unternehmensarchitektur zu erstellen. Das Ergebnis ist in Abbildung 8-2 dargestellt.

Konzentrieren Sie sich auf die Ebene der Anwendungslogik. Abbildung 8-2 zeigt, dass der Zugriff auf die Anwendungslogik das Fassadenmuster verwendet. Eine Fassade ist ein Objekt, das eine vereinfachte Schnittstelle zu einem größeren Codekörper bereitstellt, z. B. einer Klassenbibliothek. Eine Fassade kann externe Code-Abhängigkeiten von den inneren Abläufen einer Bibliothek reduzieren, da der meiste Code die Fassade verwendet, wodurch mehr Flexibilität bei der Systementwicklung ermöglicht wird. Dazu wird die Fassade eine grobkörnige Schnittstelle zu einer Sammlung von feinkörnigen Objekten bieten.

Entscheidungsfluss

Die Programmflusskontrolle, auch bekannt als Entscheidungsfluss, betrifft das Entwerfen der Dienste in Ihrer Anwendungslogikschicht oder, wie Sie im vorherigen Absatz gesehen haben, das Entwerfen der Methoden in Ihrer Fassade.

Es gibt zwei Ansätze zur Organisation Ihrer Dienste:

• handlungsorientiert
• staatlich getrieben

Handlungsorientierter Ansatz

Indem Sie Dienste basierend auf Benutzeraktionen organisieren, implementieren Sie Anwendungslogik, indem Sie Dienste anbieten, von denen jeder eine bestimmte Anforderung von der Präsentationsschicht verarbeitet. Dies wird auch als Transaktionsskriptmuster bezeichnet. Dieser Ansatz ist beliebt, weil er einfach ist und sehr natürlich aussieht. Beispiele für Methoden, die diesem Ansatz folgen, sind BookStoreService.AddNewOrder(Order order) und BookStoreService.CancelOrder(int orderId).

Die zum Ausführen der Aktion erforderliche Logik wird innerhalb der Methode sehr sequentiell implementiert, wodurch der Code sehr gut lesbar, aber auch schwieriger wiederzuverwenden ist. Die Verwendung zusätzlicher Entwurfsmuster, wie z. B. des Tabellenmodulmusters, kann dazu beitragen, die Wiederverwendbarkeit zu erhöhen.

Staatlicher Ansatz

Es ist auch möglich, den Entscheidungsfluss der Anwendung viel zustandsorientierter zu implementieren. Vom Anwendungsserver angebotene Dienste sind eher generischer Natur, z. B. BookStoreService.SaveOrder(Order order). Diese Methode prüft den Status der Bestellung und entscheidet, ob eine neue Bestellung hinzugefügt oder eine bestehende Bestellung storniert werden soll.

Projekte zur Datenstruktur

Beim Entwerfen Ihrer Datenstrukturen müssen Sie mehrere Entscheidungen treffen. Die erste Wahl ist der Datenspeichermechanismus, die zweite die beabsichtigte Verwendung der Daten und die dritte die Versionsanforderungen. Es gibt drei Möglichkeiten, Datenstrukturdesigns zu betrachten:

• Die Dienste bieten Daten; data ist ein Spiegelbild der relationalen Datenbank.
• Daten müssen Objekten zugeordnet werden und Dienste ermöglichen den Zugriff auf Objekte.
• Die von Diensten angebotenen Daten müssen schemabasiert sein.

Die Auswahl einer der drei als Grundlage für Ihre Datenflussstruktur sollte in einem frühen Stadium des Designprozesses erfolgen. Viele Unternehmen haben eine Unternehmensrichtlinie, die eine von drei Optionen für alle Projekte vorschreibt, aber wenn möglich, sollten Sie die Optionen für jedes Projekt neu bewerten und den optimalen Ansatz für das jeweilige Projekt auswählen.

Auswählen einer Datenspeicher-Engine

Wenn Sie Ihre Anwendung entwerfen, müssen Sie zweifellos eine Art Datenspeicher entwerfen. Folgende Speicher und Formen der Datenspeicherung stehen zur Verfügung:

• Aufzeichnen
• app.config-Datei
• xml-Dateien
• reine Textdateien
• Datenbank
• Nachrichtenwarteschlange

Jedes Geschäft hat seine eigenen einzigartigen Eigenschaften und kann an spezifische Anforderungen angepasst werden.

Gestaltung des Datenflusses

Datenfluss mit ADO.NET

Durch die Implementierung datenzentrischer Dienste in der Anwendungslogikschicht entwerfen Sie Ihren Datenfluss mit ADO.NET. Die .NET Framework-Klassenbibliothek bietet eine umfangreiche Anwendungsprogrammierschnittstelle (API) zum Bearbeiten von Daten in verwaltetem Code. Die API wird als ADO.NET bezeichnet und befindet sich im System.Data-Namespace. Die vollständige Trennung von Datenträgern und Datenspeichern ist ein wichtiges Designmerkmal von ADO.NET. Klassen wie DataSet, DataTable und DataRow dienen zum Speichern von Daten, behalten aber keine Kenntnis darüber, woher die Daten stammen. Sie gelten als datenquellenunabhängig. Ein separater Satz von Klassen, z. B. SqlConnection, SqlDataAdapter und SqlCommand, sorgt für die Verbindung mit einer Datenquelle, das Abrufen von Daten und das Auffüllen von DataSet, DataTable und DataRow. Diese Klassen befinden sich in untergeordneten Namespaces wie System.Data.Sql, System.Data.OleDB, System.Data.Oracle usw. Je nachdem, zu welcher Datenquelle Sie eine Verbindung herstellen möchten, können Sie Klassen im richtigen Namensraum verwenden, und je nach Umfang des von Ihnen verwendeten Produkts werden Sie feststellen, dass diese Klassen mehr oder weniger Funktionalität bieten.

Da das DataSet nicht mit der Datenquelle verbunden ist, kann es sehr erfolgreich verwendet werden, um den Datenfluss in einer Anwendung zu verwalten. Abbildung 8-5 zeigt den Datenfluss dabei.

Schauen wir uns dieses Projekt an und stellen uns vor, jemand hat sich in Ihren Buchladen eingeloggt und drei Bücher bestellt. Die Präsentationsschicht verwaltet den Zustand des Einkaufswagens. Der Kunde ist zur Bestellung bereit und hat alle erforderlichen Daten angegeben. Er entscheidet sich für die Bestellung. Die Webseite wandelt alle Daten in ein DataSet um, das zwei DataTables enthält, eine für die Bestellung und eine für die Bestellung; fügt eine DataRow für die Bestellung ein; und fügt drei DataRows für die Auftragszeilen ein. Die Webseite zeigt diese Daten dann erneut dem Benutzer an, bindet Datenkontrollen an das DataSet und fragt Sind Sie sicher? Der Benutzer bestätigt die Anfrage und sie wird an die logische Schicht der Anwendung übermittelt. Die Anwendungslogikschicht überprüft das DataSet, um festzustellen, ob alle erforderlichen Felder einen Wert haben, und führt eine Überprüfung durch, um festzustellen, ob der Benutzer mehr als 1000 US$ hat. 00 auf offene Rechnungen. Wenn alles gut geht, wird das DataSet an die Datenzugriffsschicht übergeben, die eine Verbindung zur Datenbank herstellt und Einfügeanweisungen aus den DataSet-Informationen generiert.

Die Verwendung des DataSets auf diese Weise ist eine schnelle und effiziente Möglichkeit, eine Anwendung zu erstellen und die Leistungsfähigkeit der Framework-Klassenbibliothek und die Fähigkeit von ASP.NET zu nutzen, Daten an verschiedene Steuerelemente wie GridView für ein DataSet zu binden. Anstatt einfache DataSet-Objekte zu verwenden, können Sie typisierte DataSet-Objekte verwenden und die Codierungserfahrung verbessern, indem Sie Code sowohl in der Präsentationsschicht als auch in der Anwendungslogikschicht implementieren. Der Vorteil dieses Ansatzes ist gleichzeitig der Nachteil des Ansatzes. Kleine Änderungen am Datenmodell führen nicht zwangsläufig dazu, dass viele Methoden ihre Signaturen ändern müssen. In Bezug auf die Wartung funktioniert dies also wirklich gut. Wenn Sie sich daran erinnern, dass die Präsentationsschicht nicht unbedingt eine Benutzeroberfläche ist, kann es sich auch um einen Webdienst handeln. Und wenn Sie die Definition des DataSet ändern, vielleicht weil Sie ein Feld in der Datenbank umbenennen, dann ändern Sie den Vertrag, den der Webdienst abonniert. Wie Sie sich vorstellen können, kann dies zu einigen erheblichen Problemen führen. Dieses Szenario funktioniert gut, wenn die Präsentationsschicht nur eine Benutzeroberfläche ist, aber für Schnittstellen zu externen Systemen oder Komponenten möchten Sie das Innenleben Ihrer Anwendung verbergen und Daten in etwas anderes als einen direkten Klon Ihres Datenmodells umwandeln und Sie möchten Data Transfer Objects (DTOs) erstellen.

Datenfluss mit objektrelationalem Mapping

Der Datenfluss mit ADO.NET ist ein sehr datenzentrierter Ansatz zur Verwaltung des Datenflusses. Daten und Logik sind diskret. Das andere Ende des Spektrums verfolgt einen eher objektorientierten Ansatz. Hier werden Klassen erstellt, um Daten und Verhalten zu gruppieren. Das Ziel besteht darin, Klassen zu definieren, die die Daten und das Verhalten in der Geschäftsdomäne nachahmen, für die die Anwendung erstellt wurde. Das Ergebnis wird oft als Geschäftsobjekt bezeichnet. Die Sammlung von Geschäftsobjekten, aus denen die Anwendung besteht, wird als Domänenmodell bezeichnet. Einige Entwickler behaupten, dass ein umfassendes Domänenmodell besser zum Entwerfen komplexerer Logik geeignet ist. Es ist schwierig, eine solche Aussage zu beweisen oder zu widerlegen. Wisse nur, dass du die Wahl hast und es an dir liegt, sie zu treffen.

Abbildung 8-6 zeigt einen ähnlichen Datenfluss wie Abbildung 8-5, außer dass Sie jetzt die objektrelationale Mapping-Schicht hinzugefügt und die DataSet-Objekte durch andere Datenträger ersetzt haben.

Gehen Sie nun Schritt für Schritt vor wie zuvor; Stellen Sie sich vor, jemand hat sich mit Ihrer Buchhandlung verbunden und drei Bücher bestellt. Die Präsentationsschicht verwaltet den Status des Einkaufswagens. Der Kunde ist zur Bestellung bereit und hat alle erforderlichen Daten angegeben. Er entscheidet sich für die Bestellung. Die Webseite verwandelt alle Daten in ein DTO, das Daten für eine Bestellung und mit drei Bestellzeilen enthält und die Objekte nach Bedarf erstellt. Die Webseite zeigt dem Benutzer diese Daten noch einmal an, steuert die Datenbindung anhand des DTO unter Verwendung von ObjectDataSource in ASP.NET 2.0 und fragt Sind Sie sicher? Der Benutzer bestätigt die Auswahl und das DTO wird an die logische Schicht der Anwendung übermittelt. Die Anwendungslogikschicht wandelt das DTO in ein Geschäftsobjekt des Typs Order mit einer Eigenschaft um, die drei OrderLine-Objekte enthalten soll. Die Order-Methode. Validate() wird aufgerufen, um den Auftrag zu validieren und zu überprüfen, ob alle erforderlichen Felder einen Wert haben, und es wird geprüft, ob der Benutzer mehr als R$ 1.000,00 an ausstehenden Belegen hat. Dazu ruft die Bestellung Order.Customer.GetOutstandingBills() auf. Wenn alles in Ordnung ist, wird die Methode Order.Save() aufgerufen. Die Anforderung durchläuft die objektrelationale Mapping-Schicht, wo die Anforderung und die Zeilen der Anforderung einer DataTable in einem DataSet zugeordnet werden, und das DataSet wird an die Datenzugriffsschicht übergeben, die eine Verbindung zur Datenbank herstellt und Einfügeanweisungen generiert die Informationen im DataSet. Es gibt natürlich viele Möglichkeiten, wie eine objektrelationale Abbildung erfolgen kann, aber nicht alle beinhalten eine Transformation in ein DataSet. Einige erstellen die Insert-Anweisung direkt, verwenden aber dennoch die Datenzugriffsschicht, um diese Anweisung auszuführen.

Wie Sie sehen können, finden einige Transformationen statt. Die Verwendung von DTOs ist notwendig, da ein Geschäftsobjekt das Verhalten implementiert und das Verhalten Änderungen unterliegt. Um die Auswirkungen dieser Änderungen auf die Präsentationsschicht zu minimieren, müssen Sie die Daten aus dem Geschäftsobjekt in ein Datenübertragungsobjekt umwandeln. In Java wird das Datenübertragungsobjekt oft als Wertobjekt bezeichnet.

Ein großer Vorteil der Arbeit mit Geschäftsobjekten besteht darin, dass es wirklich hilft, Ihren Code zu organisieren. Wenn Sie auf ein komplexes Stück Logik zurückblicken, ist es normalerweise sehr gut lesbar, weil es sehr wenig Installationscode gibt. Der Nachteil ist, dass die meisten Datenspeicher immer noch relational sind und die Zuordnung von Geschäftsobjekten zu relationalen Daten recht komplex werden kann.

schemabasierte Dienste

Sie haben gerade zwei Gegensätze gesehen, wenn es um die Verwaltung des Datenflusses geht. Viele Variationen sind möglich. Eine gängige Variante ist die Variante, bei der ein Dataset als grundlegender Datenträger der UI zum Speichern von Daten verwendet wird, aber separate Schemas (DTOs) für Webservices verwendet werden, die von anderen Systemen aufgerufen werden. Die Anwendungsschicht transformiert relationale Daten in ein vordefiniertes Schema. Der Hauptvorteil davon besteht darin, dass jede Anwendung, die auf den Dienst verweist, nicht von irgendeiner internen Implementierung der Komponente abhängt. Dies ermöglicht mehr Flexibilität bei der Versionierung, Abwärtskompatibilität von Schnittstellen und die Möglichkeit, die Implementierung der Komponente zu ändern, ohne die Schnittstelle des Dienstes zu ändern.

Natürlich können Sie Business-Objekte in der Webanwendung verwenden und die DTO-Transformation umgehen, aber das funktioniert normalerweise nur dann gut, wenn die Anwendungslogik zusammen mit der Webanwendung implementiert wird. Denken Sie daran, dass Sie zum Aufrufen von Order.Save() eine Datenbankverbindung benötigen. Ob dies wünschenswert ist, hängt von Ihnen und wahrscheinlich Ihrem Sicherheitsdirektor ab.