Ein sehr interessantes Interview zum Thema Objektrelationale Mapper mit Stephan Görgens gibt es in der einhundertachten Episode des Anwendungsentwickler-Podcasts.
Podcast: Play in new window | Download (Duration: 1:32:43 — 41.5MB)
Abonnieren: Apple Podcasts | Spotify | RSS
Inhalt
Die folgenden Fragen zum Bereich der objektrelationalen Mapper gehen wir im Verlauf des Interviews durch.
Objektrelationale Mapper
- Was ist ein ORM?
- Warum braucht man einen ORM bzw. sollte ihn verwenden?
- Was sind Beispiele für bekannte ORMs?
- Mit welchen ORMs hast du selbst schon gearbeitet?
- Was ist dein Lieblings-ORM und warum?
- Was sollte ein ORM mindestens können?
- Wie konfiguriert man einen ORM?
- Wie setzt man komplexe Datenbankabfragen mit einem ORM um?
- Wie integriert man einen ORM am besten in eine Anwendungsarchitektur?
- Ab wann „lohnt“ sich der Einsatz eines ORMs im Projekt?
- Wie stark macht man sich beim Einsatz eines ORMs von diesem abhängig?
- Sollte man einen ORM einfach austauschen können?
- Wie wichtig ist das Beherrschen von SQL, wenn man mit ORMs arbeitet?
- Sollten auch Azubis schon mit ORMs arbeiten und warum (nicht)?
- Welche Nachteile haben ORMs?
- Welche Literaturempfehlungen hast du für den Bereich ORMs?
Literaturempfehlungen
Stephan empfiehlt für Einsteiger ins Thema Moderne Datenzugriffslösungen mit Entity Framework 6: Datenbankprogrammierung mit .NET und C#* von Dr. Holger Schwichtenberg.
Und hier gibt es den „.NET-Doktor“ live zu sehen.
Außerdem ist Stephan – genau wie ich – der Meinung, dass Clean Code* auf keinem Entwicklernachttisch fehlen sollte 😉
*
Links
- Stephan erreichst du am Besten über Xing: Stephan Görgens
- Das Karriereportal von BMW findest du hier, falls du Interesse an einem Praktikum oder einer Abschlussarbeit hast: BMW Group – Karriere.
- Der .NET-Doktor (Dr. Holger Schwichtenberg)
- Die BASTA! ist sicherlich eine der interessantesten Konferenzen im .NET-Umfeld.
- Und das ist die Beispielanwendung zum Entity Framework: World Wide Wings (WWWings).
In über 15 Jahren Softwareentwicklung hatte ich ein Projekt tatsächlich mal, in dem die Datenbank getauscht wurde. Und zwar wurde dem Management die Lizenzkosten für Oracle zu teuer und es wurde entschieden auf PostgreSQL zu migrieren. Das war dann trotz JPA/Hibernate ein erheblicher Aufwand. Es gab in der Anwendung einige Stored Procedures und manche Datentypen machten Probleme und mussten speziell umgesetzt werden. Vor allem Binärdaten in Blobs. Die hat Oracle ganz anders behandelt als PostgreSQL und Hibernate hatte das nicht wirklich abstrahiert.
Autsch! Aber gut zu wissen, dass es in der Praxis auch wirklich mal relevant wird, eine Datenbank abzulösen. Der Treiber – die Kosten – ist natürlich auch nachvollziehbar! Oracle geht ganz schön ins Geld…
Wir haben ein Java-Projekt, das auf Oracle und Microsoft SQL laufen muss, weil verschiedene Kunden unterschiedliche Datenbanken verwenden.