Laden...

O/R-Mapper für XML-Dateien - Ablehung des Formats

Erstellt von zero_x vor 13 Jahren Letzter Beitrag vor 13 Jahren 1.802 Views
zero_x Themenstarter:in
1.044 Beiträge seit 2008
vor 13 Jahren
O/R-Mapper für XML-Dateien - Ablehung des Formats

Hallo zusammen,

zur Zeit programmiere ich eine Anwendung, die dazu Dient, Daten zu bearbeiten. Vorstellen kann man sich die Anwendung, wie eine simple Verwaltung von Personen und Bestellungen.

Immer sehe ich, dass man dazu Datenbanken verwendet werden. Die Daten werden in einer SQL Datenbank gespeichert und mithilfe eines O/R-Mappers werden die Klassen generiert. Für mich ist das natürlich auch der einfachste Weg, Daten zu speichern.

Auch in kleinen Anwendungen sehe ich, dass Datenbanken verwendetet werden. Ich möchte für meine kleine Anwendung die Daten in einer XML-Datei speichern. Bisher habe ich das mit LINQ gemacht. Der Nachteil daran ist leider, dass man seine Klassen in C# von Hand schreiben muss. Die Abfragen musste ich mühselig mit LINQ to XML schreiben.

Jetzt frage ich mich, warum XML oft auf Ablehnung stößt. Ich sehe keine Nachteile in XML - auf das Format bezogen. XML hat in meinen Augen alle Voraussetzungen wie eine SQL Datenbank auch.

Nach Recherche bezüglich eines O/R-Mappers für XML, bin ich zu keinem Resultat gekommen. Ich habe keinerlei Tools oder ähnliches gefunden. Trotzdem möchte ich für meine Anwendung die Daten in einer XML-Datei speichern.

D.h. möchte ich euch fragen, ob es doch wirklich Nachteile gibt. Im Grunde erfüllt XML doch alles. Kennt ihr Tools, um, wie bei Datenbanken, "Tabellen" oder Klassen zu generieren?

zero_x

297 Beiträge seit 2008
vor 13 Jahren

Das Tool "xsd.exe" kannst du aus einem XML Schema CLR-Klassen erzeugen. Gibt dazu auch mehrere Seiten im Internet, z.B. hier oder hier.

There are 10 kind of people, those who understand binary and those who don't.

F
10.010 Beiträge seit 2004
vor 13 Jahren

XML Stösst nicht auf ablehnung es ist nur für diesen Job nicht wirklich sinnvoll.

XML ist eine Datenbeschreibungssprache, die zur Ablage und zum Austausch von Daten dient.
Datenbanken sind zum effektiven Verwalten und Abfragen von Daten gedacht.

Beides überschneidet sich im Datenhaltungs teil, das war es auch schon.

XML bläht die Daten auf ( alles ist Text und jede Zeile enthält das Schema ), und Abfragen sind hier nur entweder Speicherhungrig per DOM und XPath möglich, oder nur sequentiel per XmlReader.

Datenbanken hingegen sind ja extra für so etwas gedacht, d.h. sie sind recht speicherschonend und die abfragen sind hier deutlich besser skalierbar.

Wenn du keinen DB Server installiern willst, benutze eine der embedded Datenbanken wie SQLite, Sql Compact oder Firebird Embedded.

1.820 Beiträge seit 2005
vor 13 Jahren

Hallo!

@zero_x:
Interessant für die Entscheidung ist ja auch, mit welchem Datenvolumen du aktuell arbeitest und wie sich dieses mit der Zeit entwickelt.

Nobody is perfect. I'm sad, i'm not nobody 🙁

U
282 Beiträge seit 2008
vor 13 Jahren

Wichtig ist auch, wie "planar" die daten sind. XML ist als Baum flexibler und leichter erweiterbar. Wenn du diese zusätzliche Struktur brauchst, ist XML von Vorteil

3.511 Beiträge seit 2005
vor 13 Jahren

Für flexible Strukturen kann man auch NoSql Datenbanken nehmen.

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

0
767 Beiträge seit 2005
vor 13 Jahren

Was einem OR-mapper vielleicht am nähesten kommt ist der XmlSerializer.

Der hat halt keine Features wie LazyLoading, aber mappt er das Xml auf Objekte und zurück.

loop:
btst #6,$bfe001
bne.s loop
rts

zero_x Themenstarter:in
1.044 Beiträge seit 2008
vor 13 Jahren

Hallo zusammen,

so Features wie z.B. LazyLoading kann man programmieren, das sollte kein Problem darstellen. Aber ohne mich zu wiederholen: XML hat in meinen Augen die selben Voraussetzungen wie eine lokale SQL Datenbank auch. Das Arbeiten mit XML-Dateien ist natürlich aufwendiger, stellt für mich während der Entwicklung keine wirklichen Probleme dar.

Aber warum gibt es so wenig Tools für XML? Es wurde konkret noch nicht "XML ist nicht gut, weil ... " genannt. Für mich ist es so wie eine Ablehnung.

zero_x

297 Beiträge seit 2008
vor 13 Jahren

Wie bereits gesagt ist es eigentlich nicht die Hauptaufgabe von XML als Datenbankersatz zu dienen. Es ist primär dazu gedacht, (plattformübergreifend) Daten austauschen zu können.
Im Vergleich zu DBMS gibt es dabei schon ein paar Nachteile, ob diese bei dir zutreffen, ist allerdings eine andere Frage:

  • Kein paralleler Zugriff auf eine XML-Datei durch mehrere Benutzer (höchstens du baust eine Abstraktionsschicht ein, welche die Zugriffe regelt)
  • Lesen und Schreiben der Daten auf die Festplatte idR langsam
  • Keine Rollback-Funktionalität
  • Höchstwahrscheinlich keine/nicht alle ACID-Eigenschaften

All das kriegst du bei (den meisten) Datenbanksystemen mit, bei einer XML-Speicherung musst du das alles selber hinzufügen, was einem unglaublichen Aufwand entspricht.

Ob für dich XML sinnvoll ist, hängt von vielen Faktoren ab, wie beispielsweise die Anzahl der gleichzeitigen Benutzer, die benötigte Ausfallsicherheit, die Menge der Daten, uvm.

There are 10 kind of people, those who understand binary and those who don't.

49.485 Beiträge seit 2005
vor 13 Jahren

Hallo Schlopp,

deine Argumente gegen XML stimmen für den allgemeinen Fall natürlich. Aber hier geht es ja um den Ersatz für eine lokale Datenbank, also eine Datenbank, die nur von einem Benutzer genutzt wird. Das Problem von gleichzeitigen Zugriffen entsteht da vermutlich gar nicht. Und wenn man eine XML-Datei so verarbeitet, dass man sie komplett in den Speicher lädt, dort ändert, sie am Ende komplett in eine neue Datei schreibt, dann die alte löscht und die neue umbenennt, ist diese Gesamtoperation quasi auch atomar und ein vollständige Rollback-Möglichkeit fällt nebenbei auch noch ab. Für den konkreten Fall ziehen die Argumente also nicht so stark, wie im allgemeinen.

Hallo zero_x,

XML hat in meinen Augen alle Voraussetzungen wie eine SQL Datenbank auch.

so allgemein kann man den Satz aber auch nicht stehen lassen, spätestens nachdem Schlopp aufgezeigt hat, welche massiven Unterschiede zwischen XML und DBMS bestehen. Im Laufe des Threads wurden weitere Unterschiede genannt.

Es kommt darauf an, welchen Einsatzzweck du dir für deinen O/R-Mapper vorstellt.

Wenn du z.B. Objekte für deine Konfigurationsdaten hast und diese per O/R-Mapper am Beginn des Programms laden und am Ende wieder zurückschreiben willst, spricht nichts gegen XML (auch wenn man in diesem Fall besser das [Tutorial] Das neue Konfigurationsmodell im .NET Framework 2.0 verwenden sollte).

Wenn du aber deine Modellobjekte damit verwalten willst, die während der Laufzeit ständig munter selektiert, geladen, geändert und gespeichert werden, dann bist du mit einem O/R-Mapper, der auf eine SQL-Datenbank mappt, wirklich besser bedient.

herbivore

297 Beiträge seit 2008
vor 13 Jahren

Wie bereits gesagt, ist die Frage, ob sie in diesem Fall zutreffen. Wie von dir erwähnt, kommt es darauf an, wie die XML-Daten verarbeitet werden sollen, ob sie nur am Anfang geladen und beim Programmende wieder gespeichert werden, oder ob sie ständig auf die Festplatte geschrieben werden.
Ich denke, dass es sicher einige Einsatzgebiete gibt, bei denen XML als Datenbankersatz verwendet werden kann, ob das hier der Fall ist, kann uns vermutlich nur zero_x sagen.

There are 10 kind of people, those who understand binary and those who don't.

5.941 Beiträge seit 2005
vor 13 Jahren

Hallo zero_x, Hallo zusammen

Ich sehe natürlich, das die Nachteile oder die Argumente für die Ungeeignetheit von XML als "Datenbankersatz" wohl stimmen mögen.

Aber wenn es um kleinere Datenmengen geht, sich auch den Text von herbivore durchliest, sowie es doch cool ist, die Dateien mit dem Notepad zu öffnen und zu lesen 😃.

Aus praktischen Gründen (Kein MSSQL Server zur Verfügung auf dem Webserver), sowie auch weil ich es einfach ohne Serversystem machen wollte, habe ich dann etwas eigenes entwickelt.

Im Grunde basiert es ganz unten auf LINQ to XML, aber das ist Nebensache.
Pro Klasse wird eine XML-Datei generiert und du hast dann einfach eine Liste von Objekten von deiner Klasse zur Verfügung.

Abfrage per LINQ, Rückgabe ist IEnumerable<Klasse>.

Intern arbeitet die Komponente so, wie es herbivore erklärt hat.
InMemory und atomare Operationen.

Im Anhang findest du die aktuelle Version davon zum probieren.
Achtung: Weitere Features, wie bspw. Lazyloading, Aggregation, etc... sind noch nicht implementiert, könnte man aber noch machen.

Wer also etwas komplexeres als nur 1 Klasse == 1 XML Datei / Tabelle braucht, muss schauen, ob er das so abbilden kann.
Vererbung wird allerdings unterstützt.

Per: <IEnumerable>.ToQueryable(); kann man auch entweder das oder NHibernate mit einer Datenbank verwenden 😉

Viel Spass!

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

zero_x Themenstarter:in
1.044 Beiträge seit 2008
vor 13 Jahren

Hallo zusammen,

vielen Dank für die Meinungen und Hinweise! Peter Bucher, dir auch ein Dankeschön. Nettes Beispiel.

Jetzt ist mir einiges klarer geworden. Was ich bis jetzt leider immer noch nicht verstanden habe ist, warum es keine O/R-Mapper für XML-Dateien gibt. Ich habe ja schon mehrmals gesagt, dass es im Grunde eine großen Unterschiede gibt und das man alles nachprogrammieren kann. Der Aufwand und der Nutzen davon lassen wir mal außen vor. In diesem Punkt sehe ich keine Nachteile oder Einschränkungen in irgendeiner Art und Weise. Angenommen, ich sage: "Jetzt schreibe ich mir einen eigenen O/R-Mapper für XML!". Was gibt es dagegen einzuwenden? Alles, was Datenbanken unterstützen, lässt sich - finde ich - nachprogrammieren.

zero_x

F
240 Beiträge seit 2006
vor 13 Jahren

Was ich selber gemerkt habe, als ich ein Programm übernommen hab, das primär xml als Datenhaltung benutzt hat ist, dass es mit der Zeit und vielen Daten einfach zu langsam und unflexibel wird. Bei einigen Usern lagen die Ladezeiten beim Startup jenseits der 2-5 Minuten, da die xml auf massive Größen angewachsen war, und die Objekte riesig waren. Mit Umstieg auf sqlite und rewrite der applikation bin ich bei 90% Datenkompression und durchgehend gleichbleibenden Ladezeiten von ~ 5-10 Sekunden (durch Verwendung von MEF, welches die Assemblies beim Startup nach Attributen scannt) gelandet. Es kommt immer auf den Verwendungszweck an. Ich ziehe Datenbanken vor, vorallem wenn es um Datenspeicherung geht. Mit Sqlite gibt es eine einfache Variante, die keine Installation von 3rd-Party Software erfordert, und mit sqlite.NET auch einen ado.net adapter liefert, die ich bei jeder sinnvollen Verwendung benutze.

Xml benutze ich in der Applikation nur noch über die Settings file (.net configuration model) und um den autoupdater zu füttern. Xml ist eben für sowas gedacht.

6.911 Beiträge seit 2009
vor 13 Jahren

Hallo,

warum es keine O/R-Mapper für XML-Dateien gibt

weil das R bei O/R für relationale Datenbank und nicht XML steht 😉
Einen simplen "O/X-Mapper" gibt es ja über die XML-Serialisierung (wurde bereits genannt).

Aber mächtigere O/X-Mapper - so wie der von Peter Bucher - werden i.d.R. nicht benötigt (da einer DB der Vorzug gegeben wird) und von daher gibt es eben kein großen Angebot.

Alles, was Datenbanken unterstützen, lässt sich - finde ich - nachprogrammieren.

Klar - Datenbanken werden/wurde ja auch per Code erstellt, warum sollte es sich nicht nachprogrammieren lassen? Der Aufwand lohnt sich halt nicht, aber das steht hier ja nicht zur Diskussion.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

S
142 Beiträge seit 2007
vor 13 Jahren

Wenn es sich um ein echte "Datenbank" handelt, würde ich SQLite empfehlen...
Ansonsten reicht XML völlig aus, um Klassen representativ zu speichern.

Siehe XML-Serialisierung.

PS: Linq2XML -Abfragen müssen nicht "kompliziert" sein. Nach ein wenig Übung kommt man beim Gestalten der Abfragen mit dem LinqPad sehr schnell voran.