Was sind die Vorteile der Verwendung der Datenbankabstraktion durch ORM? [geschlossen]

19

Ich beginne, das von dem von mir gewählten Framework empfohlene ORM zu verwenden, und obwohl mir die Idee der zusätzlichen Abstraktionsebene, die das ORM bietet, gefällt, beginne ich zu erkennen, was dies wirklich bedeutet. Es bedeutet, dass ich nicht mehr mit meiner Datenbank (MySQL) arbeite und alle MySQL-spezifischen Funktionen verschwunden sind, als ob sie nicht existieren.

Die Idee des ORM ist, dass es versucht, mir zu helfen, indem es alles datenbankunabhängig macht. Das hört sich toll an, aber oft gibt es einen Grund, warum ich mich für ein bestimmtes Datenbanksystem entscheide. Auf dem Weg der Datenbankunabhängigkeit nimmt der ORM jedoch den kleinsten gemeinsamen Nenner, was bedeutet, dass ich am Ende die kleinsten Funktionen habe (die von allen Datenbanken unterstützt werden).

Was ist, wenn ich weiß, dass ich die zugrunde liegende Datenbank langfristig nicht wechseln werde? Warum nicht auch auf die datenbankspezifischen Funktionen zugreifen?

jblue
quelle
2
+1: Sehr interessant. Ich war im Allgemeinen ein Befürworter von ORMs, aber ich habe RDBMS normalerweise als gleichwertig eingestuft (was ich kürzlich als falsch angesehen habe).
Steven Evers
Es klingt so, als ob Sie nur eine Bestätigung Ihrer eigenen Meinung wünschen. Ein Blog könnte besser zu Ihnen passen als eine Q & A-Site.
Sie sollten wahrscheinlich nicht mehr als das benötigen, was der ORM bietet. Sie möchten Ihre Objektdaten nur in einer Datenbank speichern, und genau das erledigt der ORM. Sie sollten keine anderen "Funktionen" benötigen.
CJ7

Antworten:

14

Ich sehe es genauso. Jede Abstraktion, die es Ihnen nicht erlaubt, bei Bedarf darunter zu gelangen, ist böse, weil sie zu allerlei hässlichen Abstraktionsinversionen in Ihrem Code führt.

Bei der Arbeit haben wir ein selbst entwickeltes ORM, das ziemlich gut funktioniert, aber in Zeiten, in denen wir etwas brauchen, das seine Funktionen nicht explizit vorsehen, gibt es eine Methode, die einen String nimmt und ihn direkt in die Abfrage einfügt, die er generiert für die Verwendung von Raw-SQL, wenn es notwendig ist.

IMO ist jeder ORM, der diese Funktion nicht besitzt, die Bits nicht wert, aus denen er kompiliert wurde.

Mason Wheeler
quelle
drops it directly into the query it's generatingHört sich interessant an. Wissen Sie, wie lange es gedauert hat, dieses ORM zu schreiben? Ich würde so etwas gerne in einem der Open-Source-ORMs sehen.
jblue
+1. Die Arbeit mit dem wichtigsten Aspekt meiner Anwendung (Daten) ist das Letzte, was ich abstrahieren und die Verbindung zu verlieren möchte.
Fosco
1
Ich mag es, wenn es nötig ist, unter Wasser zu tauchen, solange es sich dabei um das Überqueren eines metaphorischen Zauns handelt: "Hier, seid Drachen. Pass auf, was du tust."
Frank Shearar
1
@Jblue: Keine Ahnung. Es wurde alles vor Jahren geschrieben, lange bevor ich eingestellt wurde. Sie haben ein ORM eingerichtet, bevor jemand den Begriff verwendete. In unserer Codebasis wird es normalerweise nur "das Objektmodell" genannt.
Mason Wheeler
3
Genau. Für die grundlegenden und üblichen Dinge sind ORMs sehr hilfreich. Aber manchmal muss man etwas tiefer gehen, und wenn der ORM diese Fähigkeit nicht bietet, dann ist es eine weitere Quelle von Problemen für Sie.
Nikos Steiakakis
14

Der ORM nimmt den kleinsten gemeinsamen Nenner

Ich muss mit Ihrer Aussage nicht einverstanden sein. Ich werde nHibernate als Beispiel nehmen. Dieses Framework unterstützt viele Datenbanken, einschließlich der beliebtesten, unabhängig von der Version (und den unterstützten Funktionen), genau wie die meisten ORMs.

Kurzer Hinweis: Sie erwähnen nur die Datenbankabstraktion. Das ist einer der vielen Vorteile, aber ich denke wirklich, dass objektorientierte Funktionen leistungsfähiger sind (z. B. Vererbung). Und You design your domain model first...

... Zurück zur Abstraktion. Es ist nicht der kleinste gemeinsame Nenner. In nHibernate haben Sie Dialekte. Sie können denselben Code zum Abfragen verschiedener Datenbanken verwenden. Dialekte übernehmen für Sie das Feature-Management. Die richtige Aussage ist das a given dialect will try to use all the power of a given database system.

SqlServer2005Nehmen wir als Beispiel den Dialekt, der bei seiner Einführung die neuen SQL Server 2005-Paging-Funktionen nutzte. Wenn Sie diesen Dialekt verwenden, anstatt SqlServer2000nur Ihre Leistung zu steigern.

Natürlich gibt es Ausnahmen, aber in vielen Jahren der Arbeit mit nHibernate bin ich auf keine einzige gestoßen, und meine Anwendungen sind sehr datenzentriert.


quelle
+1 für die Befürwortung von NHibernate. Eine Lernkurve im Vergleich zu anderen ORMs, aber der Aufwand lohnt sich.
Richeym
1
Ich würde gerne von einigen DBAs darüber hören. Bei meinem letzten Job war Hibernate nichts als Ärger (der SQL-Code war absolut ekelhaft.)
Fosco
+1 für diesen Kommentar. Es ist genau richtig. Wenn Sie die Leistung eines guten ORM wie nHibernate (mit Caching, Lazy-Loading usw.) vergleichen, sehen Sie, warum diese Abstraktion gut ist und warum Ihre datenbankspezifischen Anforderungen weniger wichtig sind.
Chris Holmes
1
Fosco, gib nHibernate noch eine Chance. Wie bei jeder anderen Technologie muss man verstehen, was im Inneren vor sich geht, um sie richtig zu nutzen.
+1, ORM ist ein maximaler Schnittpunkt dessen, was Java mit dem, was ein bestimmter JDBC-Treiber kann, tun kann. Sie können frei wählen, wie viel in die Persistenz-Ebene Ihrer Anwendung
investiert werden soll
5

Die Idee ist ordentlich, aber ich bin noch nie so weit gekommen, ein ORM-Tool zu verwenden. Es war einfach kein Problem für mich, die SQL selbst zu schreiben (oder mit dem verwendeten Speicher umzugehen). Aber ich habe den Luxus, an einer kleineren Anzahl von Projekten mit längeren Produktlebensdauern zu arbeiten. Sobald die handcodierte SQL- und DB-Manipulation vorhanden ist, ist sie vorhanden. Außerdem können Sie dann natürlich alle direkten SQL-Abfragen bearbeiten, die Sie benötigen, ohne Ihren Prozess in die Denkweise des ORM-Tools einpassen zu müssen.

Ich denke also, die Fragen sollten lauten, bevor Sie sich auf eine stürzen:

Profitieren Sie tatsächlich von ihrer Verwendung? Sparen Sie also einen ausreichenden Aufwand, indem Sie ein ORM-Tool implementieren, damit es sich lohnt, es zu verwenden, und damit es sich lohnt, Ihrem System eine zusätzliche Komplikation hinzuzufügen? (Dies gilt insbesondere für kommerzielle Apps, bei denen dieses zusätzliche Teil jetzt ein zusätzlicher Vektor für potenzielle Supportprobleme ist.)

Und wird sich dann die zusätzliche Abstraktionsebene negativ auf die App auswirken? Wird es langsamer als handcodiertes SQL usw. sein?

GroßmeisterB
quelle
5

O / RM wurde regelmäßig kritisiert. Ted Neward nannte es vor einigen Jahren das " Vietnam der Informatik ". O / RM

Fängt gut an, wird mit der Zeit komplizierter und schließt seine Benutzer in Kürze in eine Verpflichtung ein, die keinen klaren Abgrenzungspunkt, keine klaren Gewinnbedingungen und keine klare Exit-Strategie hat.

Sofern Sie nicht einfach ein eigenes Ad-hoc-Mapping schreiben (was in vielen Fällen eine gute Lösung ist, wie andere bereits gesagt haben), könnten Sie Alternativen wie die Verwendung einer nicht relationalen Datenbank in Betracht ziehen. Einige sagen, dass eine echte Objektdatenbank besser ist, andere Schlagworte, die in diesem Zusammenhang erwähnt werden, sind LINQ, Ruby und Tutorial D. Ich nehme an, dass es im Gegensatz zu echten relationalen Datenbanken echte Objektdatenbanken gibt. In der Praxis stellte ich jedoch fest, dass die konzeptionelle Datenmodellierung - dh herauszufinden, über welche Objekte der realen Welt Sie Daten speichern möchten und in welcher Beziehung diese Objekte zueinander stehen - wichtiger ist als das Herausfinden, wie Sie Ihr konzeptionelles Modell in einem beliebigen Modell ausdrücken können Programmier- oder Datenbanksprache.

Jakob
quelle
2
Toll dort zu lesen. Ich habe den Kreis in meiner Karriere geschlossen und das Beziehungsmodell mit vollem Erfolg wieder aufgenommen.
Jé Queue
2
+1 @Xepoch - Ich hatte kürzlich eine Frage zu Face-Re-ORMs - warum wird SQL in der Kälte ausgelassen? Abstraktion, klar - aber ORM scheint SQL-Phobie zu fördern.
Sunwukung
1
@sunwukung, ich war nicht immer einverstanden, aber ich glaube jetzt, dass SQL als erstklassige Logikschicht betrachtet werden sollte, nicht nur als Drahtprotokoll.
Jé Queue
3

Was ist die Alternative?

Dies ist eine interessante Vorstellung. Indem wir die Funktionen der zugrunde liegenden Datenbank abstrahieren, verlieren wir definitiv einige der Funktionen der spezifischen Datenbankimplementierung. (Ob wir von bestimmten Datenbankfeatures abhängen sollen oder nicht, ist ein weiteres Argument.) Ich denke, dies könnte durch datenbankspezifische ORMs gelöst werden, mit denen Sie auf die spezifischen Features zugreifen können falsche Richtung.

Am Ende des Tages müssen Sie sich fragen - was ist die Alternative?

Sollten wir die Verwendung von ORMs einstellen und den gesamten Datenbankzugriff selbst schreiben? Sicher, wir verlieren möglicherweise den Zugriff auf einige Datenbankfunktionen über den ORM, aber Sie können immer auf diese zugreifen, wenn Sie Techniken der alten Schule verwenden. Am Ende überwiegen die Produktivitätsgewinne die Nachteile.

Jaco Pretorius
quelle
Ich würde die Notwendigkeit in Frage stellen, überhaupt eine rationale Datenbank zu verwenden. Es stört mich, dass die Leute sofort zu RDBMS wechseln, auch wenn sie nicht die richtige Lösung sind. Objektdatenbanken bieten beispielsweise eine sehr elegante Lösung für viele Probleme. Sind sie perfekt Nein, aber die Leute machen sich selten die Mühe, sie zu bewerten. Es gibt einen beunruhigenden Trend: "Ich muss Daten speichern, ich verwende SQL!"
Matt Olenik
6
@Matt: RDBMS sind eine sehr bewährte und gut verstandene Technologie. Es gibt Unmengen von Leuten mit Erfahrung und eine große Anzahl von Tools von Drittanbietern. Aus Unternehmenssicht ist dies von großem Wert, wenn Sie sich mit etwas überaus Wertvollem wie Ihren Daten befassen. Bei kleineren Projekten ist es immer noch von Vorteil, ein Projekt (wie einen LAMP-Webdienst) starten zu können und den größten Teil der Software direkt vor Ort und gut dokumentiert zu haben.
David Thornley
3

Ein ORM entspricht grundsätzlich " Unstored Procedures ". Dort habe ich einen Begriff geprägt.

Alles, was ein ORM macht, können Sie mit Views, Triggern und Stored Procedures replizieren. Sie helfen dabei, unformatiertes SQL zu abstrahieren, und können normalisierte Datenbanken konsistent halten. Aber es funktioniert nur in einfachen Fällen. Wenn es zu mach Daten gibt, um sie zu verarbeiten, können sie zu einem Leistungsabfall werden. (ORMs in PHP beziehen sich häufig auf das Datenskript, da die SQL Builder-Ketten nicht alles abstrahieren können.)

Aber wie immer kommt es auf die jeweilige Anwendung und Aufgabe an.

Mario
quelle
2
"Nicht gespeicherte Prozeduren" - Der richtige Begriff lautet "Parametrisiertes SQL". Sie kratzen nur an der Oberfläche, was ein ausgereifter ORM für Sie tun kann (Batching, Lazy-Loading usw.)
richeym
@richeym: Die meisten ORMs in PHP verwenden weder vorbereitete Anweisungen noch parametrisierte Platzhalter. Es ist SQL-Flucht und Verkettung den ganzen Weg. Sicher, sie bieten Vorteile auf höherer Ebene gegenüber langwierigen manuellen SQL-Abfragen. Sementisch nehmen sie jedoch Verarbeitungslogik aus der Datenbank, daher "nicht gespeicherte Prozeduren".
Mario
3

Eine Sache, die bei der Verwendung von ORMs weh tut, ist, dass viele ihrer Fans behaupten, wir müssten die SQL- und RDB-Theorie nicht mehr kennen. Die Ergebnisse variieren von lustig bis total katastrophal. Und dies trotz der Millionen Male, die ORM herstellt und Experten behaupten, dass wir die SQL- und RDB-Theorie gut kennen müssen, um ein ORM richtig zu verwenden und zu konfigurieren.

Warum Menschen ein Werkzeug, das für viele, aber nicht für alle Kontexte von Nutzen ist, in eine magische, universell einsetzbare Silberkugel umwandeln, ist mir ein Rätsel.

luis.espinal
quelle
1

Letztes Jahr habe ich an einer Inhouse-App gearbeitet, die sich häufig geändert hat, und ich war sehr froh, dass wir ein ORM verwendet haben. Die App war eine unterstützende App für ein Change Management-Team, und als sich das größere Projekt weiterentwickelte, stellte unsere kleine App neue Anforderungen an Situationen, die nicht existierten und einige Monate zuvor nicht vorhergesehen werden konnten.

Dank des ORM ( Propel , in PHP) haben wir einen Teil der Logik für den Code aufgeteilt, sodass eine Funktion den Teil "Ist Datensatz gültig" der Abfrage hinzufügte, eine andere den Sicherheitsteil ("Diese Datensätze nur anzeigen, wenn der Benutzer dies tut.") hat diese Fähigkeiten "), ... Wenn sich die zugrunde liegende Struktur geändert hat (ein zusätzliches Feld, das für die" Gültigkeit von Datensätzen "berücksichtigt werden sollte), mussten wir nur eine Funktion ändern, nicht zwanzig SQL-Klauseln.

Wir kamen aus einer Situation, in der alle (nun, die meisten) SQL-Klauseln in einer separaten XML-Datei gespeichert waren, sodass "Datenbankänderungen einfach zu handhaben wären". Glauben Sie mir, das waren sie nicht. Ein Teil war so schrecklich, dass ich ihn The Daily WTF vorlegen musste .

Wenn eine Abfrage zu kompliziert war, um sie mit Propel Criteria auszudrücken, oder wenn wir einige herstellerspezifische Funktionen benötigten (hauptsächlich Volltextsuche, da wir MySQL verwendeten), war dies mit Propel kein Problem. Sie können benutzerdefinierte Kriterien hinzufügen oder bei Bedarf Roh-SQL verwenden ( jetzt noch einfacher mit tatsächlichen Propel-Objekten zu kombinieren ). Sie können Ihre herstellerspezifischen Add-Ons problemlos zu den generierten Klassen hinzufügen, sodass Sie das Beste aus beiden Welten haben: Kein SQL in Ihrem Anwendungscode, aber mit allen Funktionen Ihres Datenbankmoduls.

Jan Fabry
quelle
1

Aber der Punkt ist, dass Sie sich von der Datenbank entfernen können, was bedeutet, dass Sie nicht so denken müssen, als wären Sie in der Datenbank.

Ich arbeite jetzt in C # und benutze LINQ sehr oft, also sehr viele fließende Methoden. Ich muss nicht darüber nachdenken, wie meine Objekte auf Programmebene gespeichert oder gefunden oder gar gespeichert werden, und auf der Ebene der Geschäftsschicht nur sehr wenig.

Sehr oft werden die von den spezifischen Datenbanken selbst bereitgestellten Methoden im DB Connector verwendet, sodass Sie diese Optimierungen erhalten, ohne wissen zu müssen, um welche es sich handelt.

Sie können weiterhin Funktionen DB-seitig schreiben. Oft kann man sie einfach durchmappen.

Und vor allem ermöglicht eine solche Trennung die Testbarkeit und zwingt Sie (ein wenig) dazu, besser strukturierten Code zu schreiben

verbrannte Hand
quelle
2
Warum müssen Sie wieder außerhalb der Datenbank programmieren? Warum machen Sie die Datenbank nicht zu einem integralen Bestandteil Ihrer Entwicklung, da Sie sich dafür entschieden haben, sie zuallererst zu verwenden? Wenn Sie kein RDBMS benötigen, warum sollten Sie ein ORM darauf setzen?
Jé Queue
1
Es ist ein wesentlicher Bestandteil. Eine Datenbank ist sehr gut darin, Beziehungen zu pflegen und durchzusetzen und Rohdaten abzurufen. Die Dinge, die Sie mit diesen Daten tun möchten, wurden höchstwahrscheinlich bereits im ORM-Wrapper behandelt. Und warum sollte man neben kritischen Dingen die Logik aus der Geschäftsschicht herausnehmen?
burnt_hand
@burnt_hand - "Aber der Punkt ist, dass Sie außerhalb der Datenbank programmieren können, was bedeutet, dass Sie nicht so denken müssen, als wären Sie in der Datenbank." Was sind die universellen Vorteile? Ich kann es als Vorteil ansehen, wenn Ihre App einfach nach einer Möglichkeit sucht, Objekte zu erhalten. Bei relationalen Daten, OLTP und Ähnlichem ist das Programmieren außerhalb der Datenbank jedoch eine Möglichkeit, große Probleme zu lösen.
Luis.espinal
@ luis.espinal - was soll das heißen, du machst dich kaputt? Ich bin wirklich neugierig. Hast du ein Beispiel?
burnt_hand
@burnt_hand - eigentlich habe ich mehrere echte Beispiele. Bei der neuesten Version handelt es sich um ein sehr großes Domänenmodell, und aus Gründen der Leistung muss das Projekt beim Start alle Zuordnungen für den Ruhezustand hochladen. Die resultierende Session Factory verbraucht bis zu 30% des verwendeten Speichers ... nur für die Bindungen. Die Codebasis ist jetzt mit dem ORM zu festgeschrieben, und es ist unmöglich, sie umzuschreiben. Dies hat nun tatsächliche Auswirkungen, da sich die Anwendung den physischen Grenzen der Hardware nähert, die ausgeführt werden sollte. Schade.
Luis.espinal
1

Mit ORMs können Sie auch auf datenbankspezifische Funktionen zugreifen. Dies hängt davon ab, welches ORM Sie verwenden und welche Funktionen es bietet.

Zum Beispiel verwenden wir im aktuellen Projekt, an dem ich arbeite, die Java-Persistenz-API und den Ruhezustand. Trotzdem verwenden wir einige datenbankspezifische Funktionen, wie z. B. die Suche in Tabellen mit Soundex.

Für mich ist der Hauptvorteil der Verwendung eines ORM nicht unbedingt, dass eine Anwendungsdatenbank agnostisch wird (obwohl dies auch eine gute Sache ist), sondern dass ich größtenteils nicht darüber nachdenken muss, wie Dinge gespeichert werden und abgerufen.

Aber an einem gewissen Punkt werden Sie wahrscheinlich über diese ohnehin denken, je nach den Anforderungen für Ihre Anwendung. Das ORM ist keine Magie.

Vetle
quelle
1

Ich habe meine eigene geschrieben, was mir das Auswählen und Einfügen erleichtert.

Jede db-spezifische Sache ist verfügbar. Ich muss nur die Abfrage selbst schreiben, bei der mir die Bibliothek hilft (ich kann '?' Und params verwenden, anstatt manuell einen Parameter zu benennen und .Add zu verwenden).

Ich denke, meine Hälfte ist zum Kotzen, zur Hälfte nützlich. Ich bekomme Hilfe in der ORM-Welt und übernehme wichtige Aufgaben in der Abfragewelt.


quelle
1

Das Schreiben von Code zum Einfügen und Auswählen, Aktualisieren inline oder mit gespeicherten Prozessen und das Zurückmappen über die DAL ist länger die Norm, eher nur in Ausnahmefällen von Vorteil. Die verfügbaren ORMs, die unterstützenden Datenbanken und Sprachen sind die Frage, die Sie sich stellen sollten, warum Sie ORM nicht verwenden.

Sie sind standardisiert, universell, entweder spezifiziert oder generisch. Außerdem ist es schneller und einfacher zu implementieren. Ich habe Subsonic, Linq-to-SQL und das Entity-Framework verwendet. Der Entwickler kann sich statt auf die Datenbankzuordnung auf die Logik und die Geschäftsregeln konzentrieren.

Nickz
quelle
1
Es gibt viele Gründe, einen ORM zu verwenden oder NICHT zu verwenden. ORMs sind kein Allheilmittel und nur sehr wenige Menschen wissen, wie man sie effektiv einsetzt. Darüber hinaus spiegelt sich die Geschäftslogik in vielen Fällen (teilweise) auf ganz natürliche Weise in den Beziehungen wider, die bereits in einem RDBMS vorhanden sind (dies war das häufigste Szenario, dem ich in der Vergangenheit und Gegenwart begegnet bin). Ein gut konzipierter RDBM hat eine starke, gut verstandene und erprobte mathematische Grundlage. Natürlich sollte nicht alles mit einem RDMB modelliert werden, aber auch ein ORM ist keine universelle Lösung.
Luis.espinal
1

Meine (einfachen) zwei Cent:

1: Es gibt ORMS und es gibt ORMS. Einige ORMS basieren auf Active Record, andere auf Data Mapper - dies ist an sich eine relevante Überlegung, die jedoch einige Untersuchungen erfordert, um die Auswirkungen zu verstehen. Im Allgemeinen - meine Erfahrung in PHP ist, dass ORMS das erstere unterstützt, nur wenige das letztere. Active Record-basierte ORMs scheinen einen von zwei Effekten zu haben: Sie de-normalisieren entweder die Datenbank oder rufen eine Vielzahl von Klassen auf, um Objektinteraktionen zu unterstützen.

2: Der Vorteil von ORMs verringert sich in direkter Korrelation mit der Komplexität der Abfrage, die Sie ausführen müssen. Wenn Sie eine nette, einfache Beziehung haben - dh Benutzer -> Beiträge, können sie sehr gut funktionieren. Aus diesem Grund (IMO) verwenden die meisten ORMs / Frameworks Beispiele wie dieses. Wenn Sie jedoch komplexe Abfragen ausführen müssen, ist die Menge an ORMQL, die Sie generieren müssen, vergleichbar mit der String-Länge einer regulären SQL-Abfrage - jedoch weniger performant, da das Objektdiagramm, das die Abfrage ausführt, den Punkt besiegt Abstraktion. Kurz gesagt: ORMs sind hervorragend für die ersten 30-50% Ihrer Datenbankaufgaben - aber für die letzten schrecklich. Ich denke, dies ist ein weiterer Grund, warum AR so weit verbreitet ist.

3: Warum aus der Datenbank verstecken? Würden Sie eine serverseitige Sprache verwenden, um Javascript zu abstrahieren?

Persönlich mische ich diese Ansätze:

  • benutze ORM für die Grundlagen, lade "Benutzer"
  • Verwenden Sie ein DAO mit mehreren vorgebackenen SQL-Abfragen (z. B. selectLike, selectWhere).
  • Erweitern Sie das DAO bei Bedarf, um spezifischere, aber wiederverwendbare benutzerdefinierte Abfragen hinzuzufügen
  • Stellen Sie einen einfachen Datenbankzugriff über das DAO bereit - dh $ data = Dao-> query (Ihre SQL-Zeichenfolge), um einmalige Abfragen auszuführen.

Nachdem das alles gesagt ist, erscheint Doctrine 2 in Kürze, was wirklich interessant aussieht.

sunwukung
quelle
0

Sie können SQL Mapper-Frameworks wie myBatis verwenden, wenn Sie SQL-Funktionen verwenden möchten.

kolchanov
quelle
Das ist keine wirkliche Antwort auf die Frage von jblue nach den Vorteilen eines solchen Mapper
Lukas Eder