Stephan Görgens über Objektrelationale Mapper

Stephan Görgens über Objektrelationale Mapper – Anwendungsentwickler-Podcast #108

Ein sehr interessantes Interview zum Thema Objektrelationale Mapper mit Stephan Görgens gibt es in der einhundertachten Episode des Anwendungsentwickler-Podcasts.

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.

*

Den erwähnten PluralSight-Kurs gibt es hier: Entity Framework Core: Getting Started*.

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 😉

Robert C. Martin - Clean Code: A Handbook of Agile Software Craftsmanship (Affiliate)

Links

2 thoughts on “Stephan Görgens über Objektrelationale Mapper – Anwendungsentwickler-Podcast #108

  1. 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.

  2. 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…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax