Einleitung
Nach jeder Menge Theorie zur Enterprise Library geht es in diesem Artikel nun um die praktische Anwendung. Im folgenden Artikel wird erläutert wie die Enterprise Library um einen eigenen Database Provider erweitert werden kann. Hierfür nehme ich ein Beispiel aus der täglichen Unternehmenspraxis. Standardmäßig wird die Enterprise Library mit Database Providern für den SQL-Server und Oracle ausgeliefert. (Hinweis: Der Oracle Provider allerdings nutzt intern den „Oracle.DataAccess.Client“ von Microsoft für die Datenbankzugriffe, dieser ist jedoch im .NET Framework als „deprecated“ gekennzeichnet und sollte somit nicht mehr verwendet werden. Also müsste die Enterprise Library dahingehend angepasst werden, dass nur noch der von Oracle bereitgestellte Provider verwendet wird. Dies ist jedoch nicht Gegenstand dieses Artikels und wird evtl. in einem nächsten Artikel näher erläutert.) In diesem Artikel soll es nun um die Erstellung eines neuen Providers gehen, denn nicht in jedem Unternehmen wird der SQL-Server bzw. Oracle eingesetzt. Mehr…
Einleitung
Wie bereits in den Grundlagen zur Enterprise Library erläutert, enthält die Enterprise Library einen einfach zu bedienenden Mechanismus mit dessen Hilfe sich die Bibliothek um benutzerdefinierte Provider erweitern lässt. Dafür stellt die Enterprise Library sogenannte Erweiterungs-Punkte (extension points) für jeden Application Block bereit. Durch den Konfigurationsmechanismus innerhalb der Enterprise Library lassen sich die benutzerdefinierten Provider ebenfalls mit dem grafischen Konfigurationstool konfigurieren (dies hängt jedoch vom jeweils verwendeten Provider ab). Mehr…
Einleitung
Hat man sich entschlossen die Enterprise Library einzusetzen und das jeweilige Projekt entsprechend vorbereitet (Verweise auf die Assemblies der jeweiligen Application Blocks, die man verwende möchte, Namespaces eingebunden, usw.) kann die Enterprise Library auch schon verwendet werden. Zunächst sollte man überlegen wie man die Objekte der einzelnen Application Blocks erzeugen möchte. Da die einzelnen Application Blocks hinsichtlich des Prinzips der losen Kopplung (loose coupling) optimiert sind gibt es für die Objekterzeugung nämlich mehrere Möglichkeiten. Mehr…
Problemstellung
Bevor nun näher auf das Dependency Injection Pattern eingegangen wird, soll zunächst einmal das Problem erörtert werden, bei dem dieses Pattern zum Einsatz kommt. In größeren Softwaresystemen arbeiten oftmals viele Komponenten oder Module zusammen. Die Kopplung zwischen verschiedenen Software-Bausteinen (Pakete, Klassen, etc.) ist ein Maß dafür wie stark diese voneinander abhängen. Mehr…
Einleitung
Jeder Softwareentwickler kennt das Problem in Unternehmensanwendungen: Das Rad muss meistens immer neu erfunden werden. In umfangreichen Geschäftsanwendungen gibt es immer wieder grundlegende Aufgaben, die zeitaufwändig oder umständlich jedes Mal aufs Neue zu erledigen sind. Um den Aufwand für diese immer wiederkehrenden Aufgaben auf ein Mindestmaß zu reduzieren stellt Microsoft die sogenannte „Enterprise Library“ zu Verfügung. Entstanden ist die Enterprise Library innerhalb der Pattern & Practices-Gruppe bei Microsoft, die die Aufgabe hat, .NET-Entwicklern geeignete Handlungsrichtlinien für den Einsatz von .NET-Technologien zu vermitteln. Diese Gruppe hat mehrere wiederverwendbar Software Komponenten, so genannte Anwendungsblöcke (Application Blocks) erstellt, die die Anwendung von bestimmten Teilen der .NET-Klassenbibliothek vereinfachen und für das Umfeld der Enterprise-Anwendungsentwicklung nutzbar machen. Die einzelnen Anwendungsblöcke zeigen Lösungen für typische Entwicklungsaufgaben in großen, mehrschichtigen, verteilten Anwendungen auf. Allgemein gesprochen stellen diese Anwendungsblöcke „Mini“-Frameworks bereit, die jeweils eine bestimmte Aufgabe kapseln und ihren Overhead verbergen. Mehr…
Die Entwicklung von Software ist ein außerordentlich komplexer Prozess, der umso problematischer wird, je umfangreicher die zu entwickelnde Software ist. Je umfangreicher ein Software-Projekt ist, desto unwahrscheinlicher ist es, dass sein Ergebnis jemals fehlerfrei wird. Man muss sogar davon ausgehen, dass es unmöglich ist, umfangreiche Software-Produkte vollständig fehlerfrei zu entwickeln. Ein anderes Problem der Software-Entwicklung besteht darin, die Software so zu entwickeln, dass sie später problemlos geändert bzw. modifiziert werden kann. Die Entwicklung eines Software-Systems ist in der Regel ein evolutionärer Prozess, der oft lange dauert und dessen Ende womöglich nicht abzusehen ist. Mehr…
