© best_vector/Shutterstock.com
Windows Developer
Teil 3: Unit of Work - schlanke Transaktionen an die Datenbank

Performance-Boost fürs Projekt

Eine allgemeingültige und für schlichtweg jedes Projekt mit hoher Priorisierung enorm wichtige Voraussetzung ist die Performance. Spätestens, wenn die ersten Acceptance-Tests durchgeführt werden und die ersten Nutzer warten müssen, gewinnt das Thema stark an Bedeutung. Unit of Work bietet die Möglichkeit, die Anzahl der Transaktionen gegen die Datenbank zu reduzieren und dadurch die Effizienz zu maximieren.

Oğuzhan Açıkgöz


ArtikelserieTeil 1: Dependency Injection in AktionTeil 2: Repository-Pattern – Kapselung der DatenschichtTeil 3: Unit of Work – schlanke Transaktionen an die Datenbank

Im letzten Teil dieser Artikelserie widmen wir uns dem Unit-of-Work-Pattern. Auf das Wesentliche reduziert geht es bei Unit of Work (UoW) um die Bündelung von Aktivitäten gegen die Datenbank und die Ausführung mit nur einer Transaktion. Außerdem fungiert das UoW als Zwischenschicht für die Repositories aus dem letzten Artikel, was bedeutet, dass sie gekapselt durch das UoW konsumiert werden können.

Motivation

Bei der Entwicklung von Businesslogiken hat der einzelne Entwickler meist keine Vorstellung davon, welche Auswirkungen schlechter Code auf die Gesamtapplikation haben kann – ihm fehlt schlichtweg das Gesamtbild der Applikation, weil nur noch Projekte paketiert und kleine Tasks mundgerecht auf die Entwickler zurechtgeschnitten werden. Umso wichtiger ist die Architekten- bzw. Softwareingenieurrolle in größeren Projekten. Entsprechend dem vielschichtigen und abstrahierten Code kann der Verantwortliche durch eine gute Architektur die notwendigen fachlichen Anforderungen festlegen und gewährleisten, dass ein Task richtig implementiert wird. In dieser Artikelserie haben wir bereits zu Anfang mit Dependency Injection und SOLID im Allgemeinen definiert, welche Voraussetzungen erfüllt sein müssen, um wartbaren, erweiterbaren und – ganz banal ausgedrückt – guten Code zu schreiben.

Wenn eine Nutzerinteraktion, bspw. um ein neues Produkt zu erstellen, dabei gleichzeitig ein anderes existierendes Produkt verändert, würde in einer Applikation ohne UoW zunächst eine Datenbankanfrage gestellt werden, um das eine Produkt zu erstellen, und eine zweite, um ein anderes Produkt zu verändern. Das heißt, zwei logische Veränderungen in der Applikation und eine äquivalente Anzahl an physischen Anfragen gegen die Datenbank. Das UoW reduziert die Anzahl der Transaktionen, indem alle Anfragen zwischengespeichert und durch ein SaveChanges() ausgeführt werden. Neben einem schöneren Code bietet das natürlich eine höhere Performance in der Applikation, weil die Datenbankzugriffe, die im Sinne der Performance vergleichsweise teuer sind, auf das Minimum beschränkt werden.

Umsetzung von UoW

Der UoW-Layer ist eigentlich nichts weiter als eine Zwischenschicht für unsere Repositories, die Transaktionen in Collections zwischenspeichert. Immer dann, wenn ein Produkt hinzugefügt wird, ist eine Methode, bspw. Insert(), aufzurufen,...

Windows Developer
Teil 3: Unit of Work - schlanke Transaktionen an die Datenbank

Performance-Boost fürs Projekt

Eine allgemeingültige und für schlichtweg jedes Projekt mit hoher Priorisierung enorm wichtige Voraussetzung ist die Performance. Spätestens, wenn die ersten Acceptance-Tests durchgeführt werden und die ersten Nutzer warten müssen, gewinnt das Thema stark an Bedeutung. Unit of Work bietet die Möglichkeit, die Anzahl der Transaktionen gegen die Datenbank zu reduzieren und dadurch die Effizienz zu maximieren.

Oğuzhan Açıkgöz


ArtikelserieTeil 1: Dependency Injection in AktionTeil 2: Repository-Pattern – Kapselung der DatenschichtTeil 3: Unit of Work – schlanke Transaktionen an die Datenbank

Im letzten Teil dieser Artikelserie widmen wir uns dem Unit-of-Work-Pattern. Auf das Wesentliche reduziert geht es bei Unit of Work (UoW) um die Bündelung von Aktivitäten gegen die Datenbank und die Ausführung mit nur einer Transaktion. Außerdem fungiert das UoW als Zwischenschicht für die Repositories aus dem letzten Artikel, was bedeutet, dass sie gekapselt durch das UoW konsumiert werden können.

Motivation

Bei der Entwicklung von Businesslogiken hat der einzelne Entwickler meist keine Vorstellung davon, welche Auswirkungen schlechter Code auf die Gesamtapplikation haben kann – ihm fehlt schlichtweg das Gesamtbild der Applikation, weil nur noch Projekte paketiert und kleine Tasks mundgerecht auf die Entwickler zurechtgeschnitten werden. Umso wichtiger ist die Architekten- bzw. Softwareingenieurrolle in größeren Projekten. Entsprechend dem vielschichtigen und abstrahierten Code kann der Verantwortliche durch eine gute Architektur die notwendigen fachlichen Anforderungen festlegen und gewährleisten, dass ein Task richtig implementiert wird. In dieser Artikelserie haben wir bereits zu Anfang mit Dependency Injection und SOLID im Allgemeinen definiert, welche Voraussetzungen erfüllt sein müssen, um wartbaren, erweiterbaren und – ganz banal ausgedrückt – guten Code zu schreiben.

Wenn eine Nutzerinteraktion, bspw. um ein neues Produkt zu erstellen, dabei gleichzeitig ein anderes existierendes Produkt verändert, würde in einer Applikation ohne UoW zunächst eine Datenbankanfrage gestellt werden, um das eine Produkt zu erstellen, und eine zweite, um ein anderes Produkt zu verändern. Das heißt, zwei logische Veränderungen in der Applikation und eine äquivalente Anzahl an physischen Anfragen gegen die Datenbank. Das UoW reduziert die Anzahl der Transaktionen, indem alle Anfragen zwischengespeichert und durch ein SaveChanges() ausgeführt werden. Neben einem schöneren Code bietet das natürlich eine höhere Performance in der Applikation, weil die Datenbankzugriffe, die im Sinne der Performance vergleichsweise teuer sind, auf das Minimum beschränkt werden.

Umsetzung von UoW

Der UoW-Layer ist eigentlich nichts weiter als eine Zwischenschicht für unsere Repositories, die Transaktionen in Collections zwischenspeichert. Immer dann, wenn ein Produkt hinzugefügt wird, ist eine Methode, bspw. Insert(), aufzurufen,...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang