![\"\"](\"https:\/\/avant-iconic.com\/wp-content\/uploads\/2024\/01\/DALL\u00b7E-2024-01-23-18.34.35-An-artistic-representation-of-a-UML-Unified-Modeling-Language-diagram-focusing-on-its-structure-and-elements-but-without-any-text.-The-image-shoul-300x300.png\")
<\/figure>\n\n\n\nEine Bestandsaufnahme<\/h2><\/div>\n\n\n\n
Viele einf\u00fchrende Programmierkurse an Universit\u00e4ten und Fachhochschulen halten immer noch an der Vermittlung der klassischen objektorientierten Denkweise und Semantik fest. So werden Klassen f\u00fcr geometrische Formen, Tiere oder Fahrzeuge entworfen und einfache Spiele oder Simulationen implementiert, wo jedes Objekt der simulierten Welt auch eine Instanz einer Klasse ist. Das soll, so zumindest die Theorie, die Studenten auf die weit-verbreiteten OOP-Entwicklungstechniken vorbereiten.<\/p>\n\n\n\n
Doch selbst in der Spieleentwicklung ist mittlerweile etwa das ECS-Pattern<\/a> fest etabliert, das allenfalls oberfl\u00e4chlich mit OOP zu tun hat, indem es meist die Klassen-Syntax der Programmiersprache nutzt.<\/p>\n\n\n\n Noch deutlicher ist die Diskrepanz im Backend. Hier nutzen die meisten Systeme das Design Pattern (auch Entwurfsmuster genannt) der Dependency Injection. Klassische Beispiele hierf\u00fcr sind ASP.NET (Core), Spring Boot, Nest.JS oder Laravel, im Frontend-Bereich ist auch Angular zu erw\u00e4hnen. Dieses Pattern hat zweifellos seinen Ursprung in der Objektorientierung und wurde oft dazu genutzt, die SOLID-Prinzipien<\/a> umzusetzen. Es \u00fcberwindet jedoch, genauso wie SOLID, auch ein St\u00fcck weit die Einschr\u00e4nkungen und Probleme von OOP. Es \u00e4hnelt heute in der Praxis eher einer Art flexiblem Modulsystem und steht in Konkurrenz zu Konstrukten wie ES6-Modulen oder C- und C++-Includes.<\/p>\n\n\n\n Woran kann man diese gewagt erscheinende Behauptung festmachen? Ganz einfach: Ein typisches API-Projekt in ASP.NET Core oder Spring Boot besteht aus Controllern und Services. Diese besitzen meist keinen Zustand, kapseln aber daf\u00fcr die gesamte Funktionalit\u00e4t. Die DTOs, also Datenobjekte f\u00fcr den externen Gebrauch und Entities, also Datenbank-Datenobjekte, enthalten dagegen alle Daten und daf\u00fcr nahezu keine eigene Funktionalit\u00e4t. Genau also wie ordentlicher nicht-OOP-Code in C oder JavaScript.<\/p>\n\n\n\n Diese Trennung von Funktionalit\u00e4t und Daten wurde noch vor wenigen Jahren von OOPlern als „prozedural“ angeprangert. Damals galt prozeduraler Code als grunds\u00e4tzlich schlecht. Objekte sollten immer Daten und <\/em>Funktionalit\u00e4t enthalten und die Daten so gut wie m\u00f6glich kapseln (wobei die Sprachen Java und C# daf\u00fcr nie optimal geeignet waren).<\/p>\n\n\n\n Das hat aufgeh\u00f6rt, zumindest was die Nutzung der eben erw\u00e4hnten Frameworks angeht. Nat\u00fcrlich gibt es auch Hybridl\u00f6sungen, die meist auf einer Variante der Hexagonal Architecture<\/a> beruhen, wo das Framework lediglich in einem Adapter verwendet wird. Der Applikationskern kann dann nach reiner OOP-Lehre geschrieben sein. Aber auch hier wird durch das System der Adapter implizit zugegeben, dass OOP nicht das Ma\u00df aller Dinge ist.<\/p>\n\n\n\n In der Praxis trifft man die vollst\u00e4ndige hexagonale Architektur eher selten an. Die Applikation ist meist in einem Stil geschrieben, der zwar wie ECS in der Regel syntaktisch Klassen und Objekte verwendet. Semantisch jedoch ist sie eher eine Mischung aus funktionalem und prozeduralem und idealerweise auch deklarativem Code. Diese Systeme sind meist \u00fcbersichtlicher, oft leichter testbar und brauchen insgesamt wenige Codezeilen f\u00fcr dieselbe Funktionalit\u00e4t als mit traditionellem OOP.<\/p>\n\n\n\n Eine interessante Parallele zwischen Dependency Injection und funktionaler sowie deklarativer Programmierung ist auch, dass die Abh\u00e4ngigkeiten explizit angegeben werden m\u00fcssen. Das macht es leichter, zustandsbedingte Bugs zu vermeiden.<\/p>\n\n\n\n Sogar in der UI-Entwicklung hat die Objektorientierung ihren Platzhirsch-Status teilweise eingeb\u00fc\u00dft. Seit 2020 zeigt etwa React mit seinen Functional Components und Hooks<\/a>, dass auch ein funktionaler Ansatz geeignet ist, um Komponenten und ganze Oberfl\u00e4chen mit viel State-Management zu entwickeln. Dieser Ansatz vermeidet sogar eine Reihe von Fehlerquellen. Auch Alternativen wie Svelte<\/a> sind modulorientiert und deklarativ und haben nichts mehr mit Objektorientierung zu tun. Es ist zu erwarten, dass auch bei Desktop-UIs bald \u00e4hnliche Techniken Einzug halten.<\/p>\n\n\n\n Aber wie konnte die objektorientierte Programmierung nahezu unbemerkt von der Bildfl\u00e4che verschwinden? Wie sind wir wieder bei der modularen Programmierung<\/a> nach David Parnas gelandet? Und das trotz der st\u00e4ndigen Warnungen vor prozeduralem Code?<\/p>\n\n\n\n Die Antworten sind meines Erachtens schon in der Hochzeit der OOP zu suchen. Die realen und imagin\u00e4ren Versprechungen des neuen Programmierparadigmas waren gro\u00df. Viele hatten noch im Kopf, wie das altbekannte GOTO abgeschafft und gegen Schleifen und Funktionen getauscht wurde. Sie erhofften sich, dass der Wechsel von strukturierter und prozeduraler Programmierung auf OOP einen \u00e4hnlichen Produktivit\u00e4tszuwachs bringen w\u00fcrde. Und tats\u00e4chlich: Die GUIs machten dank OOP massive Fortschritte und auch Spiele und Simulationen profitierten vom neuen Paradigma, wenn auch Klassen mit zehntausenden von Zeilen als Zeugen der neuen Komplexit\u00e4t keine Seltenheit waren.<\/p><\/div>\n\n\n\n Doch im Bereich Gesch\u00e4ftsanwendungen und in der aufkommenden Webentwicklung hatte es OOP schwer. Die meisten Entwicklerteams wussten, dass sie OOP als das neue Paradigma nutzen sollten,<\/em> doch viele empfanden die neue Technik als zu kompliziert und programmierten weiter prozedural und nutzten lediglich Framework-Klassen, ohne eigene zu erstellen, andere erstellten umfangreiche Objektmodelle mit viel Vererbung und vielen Zustandspermutationen, was sich dann in schwer nachzuverfolgenden Bugs \u00e4u\u00dferte. Design Patterns gab es zwar, jedoch herrschte noch die Meinung vor, dass Objekte in erster Linie die reale Welt abbilden sollten und Design Patterns gibt es dort eben nicht.<\/p><\/div>\n\n\n\n Mitte der 2000er wuchs die Popularit\u00e4t von Clean Code, TDD und Dependency-Injection-Frameworks an, getragen von OOP-Pionieren der ersten Stunde wie Kent Beck und Robert C. Martin. Der OOP-Trend bekam neuen R\u00fcckenwind. Sowohl die de-facto-prozeduralen Programmierer als auch die Ersteller der komplizierten Vererbungshierarchien wurden von dieser neuen Bewegung hart ins Gericht genommen. Ein dizipliniertes Vorgehen und strenge Regeln sollten OOP nun tats\u00e4chlich zum durchschlagenden Erfolg verhelfen. Gleichzeitig begann im Hintergrund der Aufstieg von JavaScript, einer Sprache mit stark funktionalen Elementen, und funktionalen Features wie LINQ in C# oder List Comprehensions in Python.<\/p><\/div>\n\n\n\n Tats\u00e4chlich haben die neuen OOP-Regeln, konsequent umgesetzt, einiges bewirkt. Doch war das komplex zu erreichen, und die urspr\u00fcnglichen gro\u00dfen Versprechen der OOP verschwanden sang- und klanglos. Hier einige davon: <\/p><\/div>\n\n\n\n Das Versprechen extremer Wiederverwendbarkeit ist der „Klassiker“ der nicht eingehaltenen Versprechen, dessen Nichteinhaltung auch viele eingefleischte OOP-Fans schnell eingestehen. Als in den 1990er-Jahren mit der gro\u00dffl\u00e4chigen Einf\u00fchrung von C++ die gro\u00dfe OOP-Welle \u00fcber die Softwarebranche hereinbrach, wurde pausenlos von der massiv verbesserten Wiederverwendbarkeit objektorientierten Codes gesprochen, damals in erster Linie durch Implementierungsvererbung. Frameworks wie Embarcadero Delphi, das es heute noch gibt, zeugen von dieser Philosophie.<\/p><\/div>\n\n\n\n Die Realit\u00e4t war eher ern\u00fcchternd und der Prozentsatz an wiederverwendbarem Code stagnierte. Zu viel Zustand, der zu verwalten war und der nach der traditionellen OOP-Lehre geradezu w\u00fcnschenswert war, machte es schwer, Objekte in verschiedenen Kontexten zu verwenden, ohne spukhafte Fernwirkungen zu erzeugen. Was uns die OOP-Community daf\u00fcr aber geschenkt hat war eine neue Variante der Bibliotheken mit eigenen Vor- und Nachteilen: die Frameworks. Diese erleichtern viele Aufgaben, sind aber aufw\u00e4ndig in der Architektur und werden daher in der Regel zugekauft oder als Open-Source-Paket integriert. F\u00fcr die interne Wiederverwendung von Code sind Frameworks dagegen oft wenig attraktiv.<\/p><\/div>\n\n\n\n Hier sind wiederum funktionale L\u00f6sungen \u00fcberlegen. Seit der Einf\u00fchrung von Functional Components in React etwa hat so gut wie jedes komplexere Projekt Custom Hooks<\/a>. Diese sind deutlich einfacher zu erstellen und viel modular als riesige, projekt- oder firmenspezifische Frameworks. Bei der Vorg\u00e4ngertechnik der Class-based components konnte man auch mit funktionalen Techniken arbeiten, aber deutlich eingeschr\u00e4nkter und vor allem mit weniger Wiederverwendungsm\u00f6glichkeiten.<\/p>\n\n\n\n Die Einf\u00fchrung von OOP und schon die Beschreibung der ersten objektorientierten Sprache, Simula, thematisierte immer wieder, dass die objektorientierte Programmierung viel n\u00e4her an der nat\u00fcrlichen Denkweise des Menschen sei. \u00dcberall um uns herum befinden sich Objekte mit verschiedenen Identit\u00e4ten und Eigenschaften, mit<\/em> denen man etwas tun kann. Das Gehirn hat nach dieser Lesart also st\u00e4ndig mit Objekten zu tun. Das h\u00f6rt sich erst einmal schl\u00fcssig an.<\/p><\/div>\n\n\n\n Doch hier liegt ein Denkfehler vor. Denn OOP-Programme arbeiten mit Ausdr\u00fccken wie Einem „Sprechen mit dem Computer“ kommen prozeduralen Sprachen oder auch praktisch alle Shell-Scriptsprachen wie Bash oder PowerShell mit ihrer Syntax bereits n\u00e4her als funktionale Sprachen oder gar OOP. Auch deklarative Ans\u00e4tze, wie man sie in ganz verschiedenen Sprachen erfolgreich einsetzen kann, \u00e4hneln der menschlichen Ausdrucksweise. In Zukunft k\u00f6nnten Large Language Models noch eine gr\u00f6\u00dfere Ann\u00e4herung daran bringen. Die St\u00e4rke von OOP ist das aber gerade nicht.<\/p><\/div>\n\n\n\n Wenn man (sinnvollerweise!) Implementierungsvererbung vermeidet und oft auf Interfaces setzt, ist die Diskrepanz noch extremer. Wer denkt schon von seinem Auto als War die Objektorientierung ein v\u00f6lliger Irrweg? Das w\u00e4re eine \u00fcbertriebene Aussage. Denn viele Techniken w\u00e4ren ohne die OOPler und ihr Umfeld nicht oder wom\u00f6glich erst viel sp\u00e4ter entstanden, und viele funktionieren sogar noch besser in einem nicht-OOP-Umfeld als mit OOP selbst.<\/p><\/div>\n\n\n\n Robert C. Martin, genannt „Uncle Bob“ und Erfinder der SOLID-Prinzipien, hat sich vor einigen Jahren wohlwollend \u00fcber Clojure und das funktionale Paradigma ge\u00e4u\u00dfert<\/a> und empfindet dieses offenbar als sehr kompatibel mit seinen Ideen.<\/p><\/div>\n\n\n\n Die folgenden Ideen aus dem OOP-Umfeld lohnt es sich auf jeden Fall zu studieren und in die Zukunft zu \u00fcbernehmen.<\/p><\/div>\n\n\n\n Auch wenn striktes TDD, vor allem f\u00fcr schlecht spezifizierte Probleme oder f\u00fcr Frontend-Logik, oft wenig zielf\u00fchrend ist, ist die Technik, zuerst einen Test zu schreiben und diesen dann zu erf\u00fcllen, ein wichtiges Werkzeug im Arsenal eines Entwicklers.<\/p><\/div>\n\n\n\n Extrem n\u00fctzlich ist diese Technik auch als Vorbereitung auf ein umfangreiches Refactoring. Hier wird zuerst die aktuelle Implementierung validiert und dann nach jedem Refactoring-Schritt \u00fcberpr\u00fcft, ob immer noch alles funktioniert. OOPler haben zwar das automatisierte Testen nicht erfunden, aber enorm weiterentwickelt.<\/p><\/div>\n\n\n\n Auch um Bugs zu beheben, eignet sich eine leicht adaptierte Variante der Technik. Man tastet sich mit „gr\u00fcnen“, also erfolgreich durchlaufenden, Tests, an den Bug heran. Dann isoliert man ihn mit einem fehlschlagenden Test und findet dann in der Regel sofort die Stelle, wo sich der Bug versteckt und kann ihn dann beheben. Die bereits erfolgreichen Tests verringern die Wahrscheinlichkeit deutlich, dass die vemeintliche Behebung einen anderen Bug zum Vorschein bringt.<\/p><\/div>\n\n\n\n Interessanterweise geht TDD bei funktionalem Code meist leichter von der Hand als mit OOP, da weniger „Ger\u00fcstbau“ notwendig ist, um den Code zum Laufen zu bekommen.<\/p><\/div>\n\n\n\n Der Begriff Refactoring stammt urspr\u00fcnglich von Martin Fowler<\/a> und wurde von ihm eher eng definiert als „diszipliniertes Verfahren, um einen bestehenden Programmcode umzustrukturieren, wobei die interne Struktur ge\u00e4ndert wird und das Verhalten nach au\u00dfen gleich bleibt“ (Quelle<\/a>). Martin Fowler war und ist eine wichtige Figur in der OOP-Community.<\/p><\/div>\n\n\n\n Ganz so streng wie Fowler nehmen viele die Definition von Refactoring nicht, so werden im Rahmen sogenannter Refactorings in der Praxis auch gerne einmal der Funktionsumfang erweitert, die Oberfl\u00e4che verbessert oder Sicherheitsl\u00fccken geschlossen. Fowler pl\u00e4diert f\u00fcr einen kleinschrittigen Refactoring-Prozess und sieht daher eine Kombination mit Erweiterungen als fehleranf\u00e4llig an.<\/p><\/div>\n\n\n\n Grunds\u00e4tzlich ist dem auch beizupflichten, moderne Versionskontroll-Systeme, wie der derzeitige Monopolist Git, haben diese Problematik aber etwas entsch\u00e4rft. Denn solange man auf Commit-Ebene die Refactorings sauber von den Erweiterungen oder Fehlerbehebungen trennt, lassen sich auch alle \u00c4nderungen sauber voneinander entflechten, wenn das n\u00f6tig sein sollte.<\/p>\n\n\n\n Regelm\u00e4\u00dfiges Refactoring, oder besser noch, Refactoring als Vorbereitungsschritt vor jeder Software\u00e4nderung, ist wichtig. Und das v\u00f6llig unabh\u00e4ngig vom Programmierparadigma. Es hat sich enorm als Instrument bew\u00e4hrt, um die Qualit\u00e4t von Software zu verbessern. Im Gegensatz zur Feature-Entwicklung geht es meist schneller<\/em> von der Hand, als man denkt, vor allem, wenn Tests in der richtigen Granularit\u00e4t vorliegen.<\/p><\/div>\n\n\n\n Hier liegt aber auch die Crux. Sind Tests zu kleinteilig (viele „Solitary Unit Tests“ nach Fowlers Terminologie, vielerorts oft nur „Unit Tests“ genannt, wobei dann alles andere ein „Integration Test“ ist), muss man die Refactoring-Arbeit schnell doppelt machen, einmal im Code und einmal in den Tests, kann aber Fehler genau lokalisieren. Andererseits sind grobschl\u00e4chtige End-To-End-Tests oder API-Tests aufw\u00e4ndig zu schreiben und helfen nicht so sehr bei der Fehlerfindung, schlagen aber selten falschen Alarm. Zu entscheiden, welche Tests man schreiben soll, ist teilweise eine „Wissenschaft f\u00fcr sich“ und wird in zuk\u00fcnftigen Beitr\u00e4gen noch Thema sein.<\/p><\/div>\n\n\n\n Die Technik der Dependency Injection ist zwar, wie wir gesehen haben, nicht immer objektorientiert, stammt urspr\u00fcnglich aber aus diesem Umfeld. Eine wichtige Errungenschaft durch Dependency Injection ist einfacheres Testen, was sich vor allem bemerkbar macht, wenn man kleinteilige Unit-Tests erstellen will. Auch hier l\u00e4sst es sich trefflich \u00fcbertreiben und dogmatisieren, aber es ist auf jeden Fall gut, die M\u00f6glichkeit, einzelne Module isoliert zu testen, immer in der Hinterhand zu haben.<\/p><\/div>\n\n\n\n Hier wird bewusst nicht von Design<\/em> Patterns gesprochen, denn da ist man schnell wieder in Gedanken bei den 23 Gang-of-Four-Patterns<\/a>, und diese sind nicht unbedingt alle gut gealtert. Singleton und Visitor in ihrer urspr\u00fcnglichen Form sind heute eher als Anti-Patterns verschrien. Was bleibt, ist aber der grunds\u00e4tzliche Gedanke, dass man die Struktur hinter guten Programmierl\u00f6sungen und gutem Code versteht und daraus eine Blaupause macht, die man wieder und wieder anwenden kann. Wichtig dabei ist nur, dass man nie davon ausgeht, bereits alle, oder auch nur die besten Patterns, gefunden zu haben.<\/p><\/div>\n\n\n\n Ein Beispiel: Momentan revolutioniert HTMX<\/a> sowohl Frontend als auch Backend und l\u00f6st ein bisher erfolgreiches Architektur-Pattern, clientseitiges State-Management in Kombination mit JSON-APIs, in Teilen ab. HTMX zeigt damit, dass wir uns bisher eventuell \u00fcberm\u00e4\u00dfig auf dieses Pattern verlassen haben. Seit der offiziellen Einf\u00fchrung von HTML5 im Jahr 2014, wo auch React noch in den Kinderschuhen steckte, w\u00e4re eine Library wie HTMX bereits m\u00f6glich gewesen. Aber erst jetzt setzt sich dieser Ansatz durch.<\/p><\/div>\n\n\n\n Die Softwarekategorie der ORMs (Object Relational Mapper) kommt ganz klar aus der objektorientierten Community. Sp\u00e4testens als sich Java durchsetzte, wuchs der Bedarf, objektorientierte Systeme an die schon l\u00e4nger g\u00e4ngigen relationalen Datenbanken anzubinden. Imagebasierte Systeme wie Smalltalk, wo die Daten einfach als Objekte im Image verwaltet wurden, waren im Verschwinden begriffen, und objektorientierte Datenbanken waren den meisten Entscheidern zu nischig und auch noch nicht lizenziert. Also SQL. Doch aus den Datenmengen, die ein Es ist nicht wegzudiskutieren, dass ORMs wie TypeORM, Prisma, Hibernate oder Entity Framework Core die Entwicklung von stark datenbankbasierten Anwendungen sehr beschleunigt und vereinfacht haben. Eigentlich ist die Bezeichnung ORM mittlerweile etwas ungenau, denn ORMs lassen sich sehr gut auch in rein prozeduralem oder in Code mit funktionalen Elementen einsetzen. Insbesondere Entity Framework Core ist hier hervorzuheben, da es nahtlos mit dem C#- und .NET-Feature LINQ zusammenarbeitet und funktionale Operationen wie Map (C#: Nichtsdestotrotz gibt es auch hier Schattenseiten. Man handelt sich etwa, insbesondere bei einem OOP-Ansatz, zwei oft sehr \u00e4hnliche Objektkategorien ein: Entities, also Datenbankobjekte und Dom\u00e4nen-Objekte oder bei einem weniger objektorientierten Ansatz DTOs. Diese beiden Objektkategorien ineinander umzusetzen kann, vor allem bei Sprachen wie Java oder C#, die kein Duck-Typing bzw. strukturelle Typisierung unterst\u00fctzen, viel Boilerplate-Code oder eigene Libraries<\/a> erfordern. Hier zeigt sich der „Object-relational impedance mismatch\u00a8 dann doch wieder, was zeigt, das ORMs allenfalls syntaktisch Objekte erzeugen, aber nicht semantisch.<\/p><\/div>\n\n\n\nOOP im Backend<\/h3><\/div>\n\n\n\n
Implizite Einschr\u00e4nkung der OOP-Nutzung<\/h4><\/div>\n\n\n\n
OOP im Frontend und UI<\/h3><\/div>\n\n\n\n
Gebrochene Versprechen von OOP<\/h2><\/div>\n\n\n\n
Pragmatismus, Umsetzungsschwierigkeiten und Regeln<\/h3><\/div>\n\n\n\n
Wiederverwendbarkeit<\/h3><\/div>\n\n\n\n
Bessere \u00dcbereinstimmung mit dem menschlichen Denkmodell<\/h3><\/div>\n\n\n\n
invoice.save()<\/code> oder fileSystemSaver.save(invoice)<\/code>. Kein Mensch k\u00e4me von selbst auf die Idee, seine Rechnung anzuweisen, sich selbst zu speichern (urspr\u00fcngliche OOP-Idee) oder sich einen abstrakten „Dateisystem-Speicherer“ auszudenken (neue OOP-Schule), der abstrakte Dateien speichert. Die Syntax computer.save(invoice)<\/code> entspr\u00e4che viel eher dem menschlichen Denken, das machte computer<\/code> aber zu einer \u201eGott-Klasse\u201c, was gemeinhin als Anti-Pattern gilt.<\/p><\/div>\n\n\n\nIDrivable<\/code>? Wir sehen also, dass dieses Argument sehr zweifelhaft ist oder zumindest aus sehr unterschiedlichen Perspektiven betrachtet werden kann. Im Gegensatz zur Wiederverwendbarkeit wurde dieses Argument auch bis heute wenig von der Community dementiert.<\/p><\/div>\n\n\n\nWas bleibt von der OOP-Kultur?<\/h2><\/div>\n\n\n\n
Test Driven Development (TDD)<\/strong><\/strong><\/h3><\/div>\n\n\n\n
Refactoring<\/h3><\/div>\n\n\n\n
Refactoring als Best Practice<\/h4><\/div>\n\n\n\n
Dependency Injection<\/strong><\/h3><\/div>\n\n\n\n
Patterns<\/strong><\/h3><\/div>\n\n\n\n
Object Relational Mapping (ORM)<\/h3><\/div>\n\n\n\n
SELECT<\/code>-Statement zur\u00fccklieferte, Objekte mit verkn\u00fcpftem Verhalten zu machen und diese dann auch wieder korrekt in die Datenbank zur\u00fcckzuspeichern, stellte sich als m\u00fchsam und fehleranf\u00e4llig heraus. Also musste eine Bibliothek her, die das erleichterte. Daraus entwickelten sich die heutigen ORMs.<\/p><\/div>\n\n\n\nVorteile von ORMs<\/h4><\/div>\n\n\n\n
Select<\/code>) oder Filter (C#: Where<\/code>) und viele andere direkt in SQL \u00fcbersetzen kann. Diese Funktionalit\u00e4t ist sogar erweiterbar und wird auch vonseiten Microsofts immer weiter vervollst\u00e4ndigt. Das ORM Prisma, geschrieben in TypeScript und Rust, zeichnet sich wiederum durch sein durchdachtes Migrations- und Schemasystem aus.<\/p><\/div>\n\n\n\nNachteile und Einschr\u00e4nkungen von ORMs<\/h4><\/div>\n\n\n\n