Frameworks - Fluch und Segen zugleich

Datum: 23.01.2019 - Kategorie: Programmierung

Frameworks sind ja nicht mehr wirklich in der Entwicklung weg zu denken. Es macht ja auch Sinn etwas wiederholendes auszulagern und an andere Stelle wieder zu verwenden. Und wenn man nun noch ein Framework nutzt das von jemand anderem erstellt und gewartet wird, hat man ja gleich nochmal weniger zu tun. Bleibt "nur noch" die Nutzung des Frameworks bei mir hängen (inkl. Einarbeitung und Konfiguration).

Hört sich ja schon mal sehr schmackhaft an aber was sollte man bei der Nutzung von Frameworks, im speziellen "externen" Frameworks, beachten und wo gibt es eventuelle Stolpersteine?

Gibt es das schon ein Rad-Framework?

Wie bereits angeschnitten, gibt es in jedem Softwareentwicklungsprojekt wiederkehrende Funktionalität. Auch sollst du nicht zwingend jedesmal das Rad neu erfinden.

Klassiker sind beispielsweise Persistierung der Daten oder Anbieten der eigentlichen Software-Funktionalitäten und Bearbeitung der Daten mit einer schönen (intuitiven) Klicki-Bunti-Oberfläche.

Im .NET-Umfeld bieten sich für diese beiden Szenarien beispielsweise das Entity Framework und die Prism Library an.

Laut offizieller Doku versprechen diese uns lästige Arbeiten abzunehmen sowie eine lose gekoppelte Oberfläche zuschaffen.

As an O/RM, EF6 reduces the impedance mismatch between the relational and object-oriented worlds, enabling developers to write applications that interact with data stored in relational databases using strongly-typed .NET objects that represent the application's domain, and eliminating the need for a large portion of the data access "plumbing" code that they usually need to write.

Entity Framework (im speziellen EF6

Prism is a framework for building loosely coupled, maintainable, and testable XAML applications in WPF, Windows 10 UWP, and Xamarin Forms.

Prism Framework

Wo ist der Haken?

Das sieht auf den ersten Blick nach einer schönen und einfachen Möglichkeit aus nervige Arbeit sowie eine erhöhte Wartbarkeit "für lau" zu bekommen. Doch solltest du einige Punkte beachten bevor du auch in deiner Software ein etwaiges Framework einsetzt.

Steigende Abhängigkeiten

Als aller Erstes holst du dir natürlich eine zusätzliche Abhängigkeit in dein Projekt. Sprich deine Software kompiliert nicht mehr oder läuft nicht korrekt, wenn ein Fehler in der externen Abhängigkeit besteht.

Bei der Nutzung von Open Source Bibliotheken kannst du dir zwar den Code herunterladen und diesen dann ggf. sogar noch anpassen. Aber dann fällt die Wartung ja auch wieder bei dir an... UND bei Problemen kann/will dir der Ersteller der Bibliothek eventuell nicht helfen, da du entweder Schund getrieben hast oder der Ersteller selbst besseres zu tun hat als einen extremen Randfall zu analyiseren und Hilfestellung zu geben.

Steigende Komplexität

Des Weiteren kann (muss aber nicht) durch jede neue Abhängigkeit auch noch die grundsätzliche Komplexität deiner Software deutlich ansteigen.

Durch das Hinzufügen der Abhängigkeit musst du dich ja in dieser nun auch noch auskennen oder diese zumindest benutzen können.

Das wird schon so passen

Bei einem kleinen privaten Projekt bin ich selbst ein bisschen auf die Nase geflogen und möchte dich gerne davor bewahren.

Im genauen habe ich bei mir den oben erwähnten ORM "Entity Framework" in mein Projekt geholt, da ich mich nicht großartig um SQL-Statements und die Persistierung meiner Daten beschäftigen wollte.

Das hat auch Anfangs super funktioniert. Neues Objekt instanziert, bearbeitet und abgespeichert. Selbiges Objekt wieder geöffnet, bearbeitet und abgespeichert. Läuft! 🙂

Jetzt kommt es aber, dass dieses Objekt eine Liste von anderen Objekten beinhalten kann. Also habe ich mich daran gemacht die nächste Ebene meines Datenmodells zu implementieren.

Dann wieder das gleiche Spiel. Vater-Objekt instanziert, bearbeitet, neue(s) Kind-Objekt hinzugefügt und gespeichert. Läuft ja wie am Schnürchen 😀

...Dachte ich zumindest. Jetzt bin ich eher zufällig darauf gestoßen, dass wenn ich das Vater-Objekt mit bereits bestehenden Kind-Objekten öffne und eines dieser Kind-Objekte bearbeitet oder ein weiteres hinzugefügt habe, das Vater-Objekt dupliziert wurde und die Änderungen nur in dem neuen Vater-Objekt persistiert waren. -> Was zum...?

Nach einiger Recherche und abrauchen von grauen Zellen, habe ich eine passende Lösung für mein Problem gefunden.

Link zu Lösung
tl;dr;

Foreignkeys über explizite Property abbilden nicht über Objekte -> diese dienen nur der Navigation

(Während der Recherche durfte ich auch feststellen, dass das Framework wohl äußerst unterschiedlich interpretiert und integriert wurde.)

Es lag schlicht und ergreifend an meiner Unwissenheit und dass auf Anhieb "alles funktionierte". Darum hatte ich mir auch nicht die Mühe gemacht mich wirklich in die Nutzung, Konfiguration und Handhabung des Entity Frameworks einzuarbeiten.

Fazit

Nur weil dir "jeder" Framework XY empfiehlt, muss es nicht zwangsweise passend für dein Anliegen sein geschweige denn korrekt von diesen Leuten genutzt werden.

Du musst nicht jedesmal das Rad neu erfinden. Wenn es bereits ein Framework gibt, dass genau dein Problem löst, du damit leben kannst dass dieses über eine (weitere) Abhängigkeit hinzufügt und ggf. die Komplexität deiner Software erhöht ABER schnell und einfach zu integrieren ist, wieso nicht?

Du solltest dir aber auch im Klaren sein wie dieses Framework funktioniert und welche Feinheiten es ggf. in deinem Projekt zu beachten gibt.