Moderne Informationstechnologien beeindrucken mit ihrer Leistungsfähigkeit, sie sind überwältigt von den sich bietenden Möglichkeiten, sie sind entmutigt von der technischen Perfektion, die ihnen innewohnt, aber es gibt einen lächerlichen Punkt, an dem die IT immer wieder ihre Zähne bricht. Zeigen Sie die Benutzerdaten aus der Datenbank an, holen Sie sich Eingaben von ihm, legen Sie sie wieder in der Datenbank ab und zeigen Sie das Ergebnis. Eingabefelder, Schaltflächen, Häkchen, Inschriften - es scheint, dass sie so unerschwinglich kompliziert sein können, dass Puzzle-Konstruktionen wie Frameworks auf Template-Engines auf Frameworks auf Transpilern erstellt werden müssen? Und warum haben wir trotz aller enormen Anstrengungen die Tatsache, dass die Spielzeugbeispiele im Tutorial natürlich einfach und angenehm gemacht werden, aber sobald das Toolkit auf die wirklichen Aufgaben des wirklichen Lebens trifft ... wie man es weicher sagt ... mit zunehmender Komplexität der zu lösenden Aufgaben, gibt es eine starke Nichtlinearität der Zunahme Umsetzungsschwierigkeiten. Nun, es wäre eine Frage von etwas wirklich Rätselhaftem auf der Ebene der theoretischen Physik oder der Weltraumtechnologie, denn es gibt sowieso keine - Schaltflächen und Häkchen. Warum vergiftet dieser Unsinn jahrzehntelang das Leben von Bürgern und Arbeitskollektiven?
Die Gründe sind wahrscheinlich wie immer viele. Wahrscheinlich sind alle auf die eine oder andere Weise erwägenswert, aber hier und jetzt werden wir über die ORM-Aufgabe (Object Relational Mapping) sprechen, die immer in irgendeiner Form hinter einigen dieser „Schaltflächen und Häkchen“ steht.
Was wissen wir über ORM?
- Das Speichern von Daten in relationalen Tabellen bedeutet nicht, dass dies eine sehr einfache Angelegenheit ist, aber im Allgemeinen sind sowohl die Idee als auch die Art ihrer Anwendung ziemlich klar und gut recherchiert.
- Bei der Objektprogrammierung ist nicht alles so gut (es gibt mehrere konkurrierende Ansätze), aber im Allgemeinen ist bei der Implementierung und Anwendung von Technologien auch alles mehr oder weniger klar.
- Sowohl das als auch das andere - über die Daten, ihre Speicherung und Verarbeitung. Das ist in der Tat ungefähr das Gleiche.
- Es erscheint uns logisch, dass es eine einfache, verständliche, bequeme, vorhersehbare und universelle Brücke zwischen den beiden Welten geben sollte.
- Und jedes Mal, wenn wir diese Brücke leicht finden, funktionieren das Unglück, ihre Einfachheit, Verständlichkeit, Bequemlichkeit, Vorhersehbarkeit und Universalität nicht über einfache Beispiele aus Tutorials hinaus.
- Jeder leidet: die Entwickler, die eine Menge extrem langweiliger Arbeit leisten müssen, und die Benutzer, die mit ungeschickter Software kämpfen müssen, und das Geschäft, dessen Verwirklichung sich plötzlich als unerträglich lang und teuer herausstellt, und die gesamte Branche.
- Ich habe viele verschiedene ORMs gesehen, aber keine guten. Das heißt, eines, das sich über einfache Beispiele hinaus nicht in eine Last und ein prokrustisches Bett verwandelt.
Warum ist alles so bizarr?
Die ideologische Grundlage der Theorie und Praxis relationaler Datenbanken ist die Prädikatenrechnung, dh ein Zweig der Mathematik. Was OOP betrifft, fehlt dort eine ähnliche ideologische Grundlage. Man kann versuchen, die Grundidee von OOP so zu formulieren: Da die Welt aus Objekten besteht, wäre es bequem, diese Welt zu modellieren, indem Objekte in einem Softwaresystem erstellt werden. In diesem Sinne zwei Fehler gleichzeitig. Erstens besteht die Welt selbst nicht und nie aus Objekten. Zweitens tut es mir leid, aber warum muss das Programm die Welt simulieren? Das heißt, wir haben eine konzeptionell falsche Aussage, die perfekt durch eine bedeutungslose Aussage des Problems ergänzt wird.
Jedes ORM ist ein Versuch, die einheitliche Entsprechung zwischen dem Zweig der Mathematik und einer losen Reihe verschiedener Praktiken klar zu erweitern, basierend auf Überlegungen zur Zweckmäßigkeit, historisch etablierten Ansätzen und oft auch auf Legenden, Meinungen von Behörden und einfach falschen Vorstellungen. In vitro kann es zum Arbeiten gebracht werden, aber in vivo ist es dazu verdammt, erbärmlich auszusehen und mehr Trauer als Freude zu bringen.
Über die Unvermeidlichkeit der Objektorientierung
Die Notwendigkeit der Objektorientierung unserer Software ist jedoch unsere unvermeidliche Realität. Diese Unvermeidlichkeit beruht in erster Linie auf der Tatsache, dass das Arbeiten mit Objekten die Essenz und Grundlage jeder unserer Aktivitäten ist. Die Welt selbst besteht nicht aus Objekten, aber um etwas in dieser Welt zu verstehen und etwas mit dieser Welt zu tun, deklarieren wir selbst ihre Teile als Objekte, nennen sie Namen, versuchen, ihr Verhalten zu verstehen, gelten für er bemüht sich, die gewünschten Ergebnisse zu erzielen. Dies ist unsere Funktionsweise, und es ist unmöglich, sie zu verlassen, und es ist nicht notwendig. Alles ist ein Objekt, nicht weil es wirklich ist, sondern weil wir es nicht anders machen können. Das, was in keiner Weise ein Objekt sein kann, liegt völlig außerhalb der Grenzen unserer Fähigkeit zu verstehen und kann nicht als Gegenstand unserer Bemühungen dienen.
Selbst wenn das Programm ohne die Verwendung von OOP-Techniken geschrieben wurde, enthält es unweigerlich Objekte (im weiteren Sinne des Wortes), indem es manipuliert, welche Probleme der Entwickler löst - Variablen, Datentypen, Operatoren, Algorithmen, syntaktische Konstruktionen, Funktionen, Module. Aus Sicht des Benutzers verfügt das Programm auch über eine Reihe von Objekten, mit denen es interagiert - Schaltflächen, Beschriftungen, Eingabefelder, Seiten, Websites und das gesamte System.
Was wir in unseren Datenbanken speichern
Wie oben erwähnt, basieren relationale Datenbanken auf Prädikatenrechnung. Ein Prädikat ist eine Tatsache, die formuliert und in unserem Fall auf einem Medium gespeichert ist. Nur für den Fall, ich stelle fest, dass es in der relationalen Datenbank nicht nur und nicht so sehr um Beziehungen zwischen Tabellen durch Fremdschlüssel geht. In der richtigen Terminologie sind Beziehungen das, was wir einfach Tabellen nennen. Das heißt, selbst wenn Ihre Datenbank nur eine Tabelle mit zwei Spalten enthält (z. B. Name und Telefonnummer), verfügen Sie bereits über eine relationale Datenbank, die die Beziehung zwischen zwei Sätzen herstellt, in diesem Fall Sätzen von Namen und Telefonnummern.
Eine relationale Datenbank speichert keine Objekte, sondern Fakten. Gespeicherte Fakten haben natürlich ein Objekt („Worum geht es bei dieser Tatsache?“). Wenn wir versuchen, dem System die Beantwortung dieser Frage beizubringen, haben wir Entitäten, dh Objekte, mit denen Fakten verknüpft sind. Wenn Sie richtig arbeiten, entsteht die Struktur unserer Basis aus einer Reihe von Antworten auf die Frage „Welche Art von Fakten wollen wir behalten?“. Und erst in der nächsten Phase erhalten wir etwas, das Objekten ähnelt, die der Objektivität Fakten verleihen. Sie können natürlich „aus Objekten“ entwerfen, aber ich würde dies nur bei Laborarbeiten in Themen empfehlen, die nicht direkt mit dem Datenbankdesign zusammenhängen. Die Gefahr schwerer architektonischer Fehleinschätzungen ist zu groß. Darüber hinaus ist es zumindest unpraktisch.
Ein kleiner Exkurs über Objektdatenbanken. Ein sehr einfacher Gedanke: Wenn wir die Probleme mit ORM satt haben, sollten wir vielleicht etwas mit dem Teil „R“ machen? Lassen Sie unsere Datenbank kein hartes und anspruchsvolles relationales Monster sein, sondern eine modische Jugend, die speziell auf die Aufbewahrung von Objekten zugeschnitten ist. Zum Beispiel eine schematische NoSQL-Basis. Am Ende stellt sich jedoch plötzlich heraus, dass NoSQL-ähnliche ORMs noch umständlicher und unnatürlicher sind als die guten alten SQL-ORMs. Auf jeden Fall können wir gerne ein schaltungsfreies DBMS betreiben, aber es gibt keine schaltungsfreien Daten in der Natur. Es gibt nichts Hilfloseres, Verantwortungsloseres und Unmoralischeres als ORM für schaltungslose Datenbanken.
Gutes ORM
Ein guter ORM ist der fehlende ORM. Nun, im Ernst. Schauen Sie sich eines Ihrer ORM-Systeme an und versuchen Sie ehrlich, Ihre Frage zu beantworten: Was sind die Vorteile dieses Monsters? Was ist der Grund für seine Verwendung, außer für unerfüllte Glücksversprechen und wiederholt voreingenommene diskreditierte? Natürlich gibt es einige nützliche nützliche Dinge, aber was sind sie vor dem Hintergrund eingeführter architektonischer Verformungen und Leistungsprobleme, die ständig aus heiterem Himmel auftreten?
In der Regel ist die Datenbank-API auf niedriger Ebene einfach, bequem, vollständig und konsistent. Normalerweise genug Finger, um alle Funktionen aufzulisten. Sie zu lernen ist keine gute Nachricht, was für eine Aufgabe.
Ich werde versuchen, eine Reihe von Architekturprinzipien zu skizzieren, mit denen Sie Objekte einer Datenbank zuordnen können, ohne ORM zu verwenden:
- Wir speichern die Fakten, bearbeiten Objekte. Denken Sie daran, dass die Datenbank Fakten speichert und die an der Datenverarbeitung beteiligten Objektmodelle Projektionen von Faktensätzen aus verschiedenen Blickwinkeln sind. Für das gegebene Beispiel mit Namen und Telefonnummern können wir beispielsweise die Abonent-Klasse haben, für die mehrere Nummern gespeichert werden können, und auch die PhoneNumber-Klasse, für die mehrere Abonnenten festgelegt werden können (vergessen Sie nicht, dass wir zusätzlich zu den persönlichen Handynummern haben wo es noch Wohnungs- und Bürotelefone gibt). Und die Tabelle in der Datenbank ist nur eine, die die Viele-zu-Viele-Beziehung zwischen vielen Namen und Telefonnummern definiert. Nur zwei verschiedene Projektionen. Übrigens lässt sich dieser Ansatz normalerweise auf viel komplexere Fälle skalieren, sodass Sie so nützliche Klassen im System haben können, wie beispielsweise "Durchschnittsumsatz für einen bestimmten Zeitraum nach einer bestimmten Kombination von Kriterien".
- Fakten werden über eine problemorientierte API in Objekte projiziert und umgekehrt. Ohne eine Lösung anzuwenden, die behauptet, universell zu sein. Wenn Sie immer noch nicht wissen, wie Sie praktische APIs erstellen, erfahren Sie, wie. Und was wichtig ist, bringen Sie sich selbst bei, sie sofort zu dokumentieren.
- Vor allem bestellen. Wenn Sie die klassische Version eines DBMS mit einem starren Datenschema verwenden, bringt dieses Schema an sich Ordnung in die Arbeit mit Daten. Die zusätzliche Struktur, die durch die Struktur der Objekte codiert wird, ist einfach redundant. Wenn Sie ein schemafreies DBMS verwenden, müssen Sie natürlich einige Anstrengungen unternehmen, um sicherzustellen, dass Ihre Datenbank nicht zu einem Müllberg wird, da verschiedene Entwickler unterschiedliche Vorstellungen davon haben, was gespeichert wird.
- DBMS-Unabhängigkeit (falls erforderlich). Wenn die für Sie interessanteste Eigenschaft von ORM die DBMS-Unabhängigkeit ist, verwenden Sie spezielle Tools wie ODBC, JDBC, ADO, oder erstellen Sie eine eigene Abstraktionsebene, falls dies nicht möglich ist. Es ist nicht so schwierig, wie es zunächst scheinen mag. Sie benötigen für Ihre Aufgabe nicht Unterstützung für absolut alle Funktionen von absolut allen DBMS, oder?
- Vergessen Sie nicht zusätzliche Aspekte der Arbeit mit Daten. B. den gemeinsamen Zugriff auf Daten (die beliebig komplex sein können), die Überwachung, die Replikation und vieles mehr. Aber hier habe ich gute Nachrichten für Sie: weil in Ihrem Lieblings-ORM das Hinzufügen. Der Aspekt wird immer noch nach dem Prinzip „Sie werden nicht allen gefallen, essen, was Sie geben“ umgesetzt. Die Ablehnung eines zweifelhaften Dienstes, mit dem Sie mehr zu tun haben als zusammenzuarbeiten, wird sich letztendlich als strategisch korrekte Entscheidung herausstellen.
Insgesamt
ORM ist ein sehr schmerzhaftes Thema für unsere Branche. In einer Zeit, in der künstliche Cloud-Intelligenz die Quantenblockkette durchpflügt, ist die überwiegende Mehrheit der Belegschaft damit beschäftigt, Geschäftslogik und eine Benutzeroberfläche mit Datenbanken zu verbinden. Millionen von Zeilen schrecklichen Codes, die mit Mikroskopen genagelt werden, Schmerz und Verzweiflung begleiten diesen kreativen Prozess überall. Eine der Wurzeln dieses traurigen Zustands ist das äußerst anhaltende Missverständnis, dass ein universelles ORM grundsätzlich möglich ist. Aber es ist unmöglich, und es gibt einen fundamentalen Grund dafür, der nicht beseitigt werden kann. Das Bewusstsein für diese Tatsache ist der erste Schritt, um aus diesem Albtraum herauszukommen. Es gibt einen Ausweg, es gibt Alternativen, aber zuerst müssen Sie erkennen, fühlen und lernen, den Fokus der Aufmerksamkeit zu behalten.
PS Ich entschuldige mich aufrichtig bei den Brüdern in diesem Beruf, die viel Zeit und Mühe investiert haben, um zahlreiche universelle Bestleistungen in der Welt von ORM zu erzielen. Es tut mir wirklich leid.