Serialisieren oder Dataset?

  • VB.NET
  • .NET (FX) 4.0

Es gibt 11 Antworten in diesem Thema. Der letzte Beitrag () ist von EDR-Temporär.

    Serialisieren oder Dataset?

    Hallo,

    Also jetzt mal rein Hypotetisch. Ich habe eine XML-Datei und diese XML Datei endhält Datensätze die ich für bestimmte Aufgaben brauche, ist es besser Objecte zu erstellen durch Deserialisierung oder sollte ich nicht besser doch auf ein DataSet zurück greifen.

    Bei den Daten handelt es sich um klar Definierte Datenstruktueren, die keine Relationalen Bezihungen zu einander aufweisen.

    Und wie verhält sich ein Dataset bei extrem Komplexten XML-Struktueren mit einer Freien Definierbaren Strukuturellen Tiefe. d.h. ein Element in Root Node hat 1 unterlement.

    Das zweite 14, von diesen haben z.B. 7 28 Unterlemente und die restlichen 7 104 unterelemente. Ich würde gerne OBJECT aus einer XML-Datei erstellen. Und kann ich bein Deserialisieren auch einfach nur "Object" verwenden oder muss ich eine DataContract klasse erstellen?

    LG, Herbrich

    man kann nicht jede Xml-Datei in ein Dataset einlesen.
    Sieh es annersrum: Ein Dataset ist eine Ansammlung von Tabellen - mehr erstmal nicht. Dank der relationalen GrundIdee kann man damit auch beliebige Verschachtelungen simulieren, und darüber hinaus auch Datenmodelle konzipieren, die mit Xml-Verschachtelung gar nicht mehr abbildebar ist.
    Aber es ist eine Ansammlung von Tabellen.
    Und es kann sich direkt auf Platte schreiben, als Xml-Datei. Und so eine von einem Dataset generierte Xml-Datei kann auch ein anneres, strukturgleiches Dataset wieder befüllen.
    Aber wie gesagt: Du kannst nicht jede beliebige Xml-Datei in ein Dataset laden.

    typisiertes Dataset hat nun immense Vorteile gegenüber per Deserialisierung erzeugen Objekten: Nämlich man kann mit Databinding sehr leistungsfähige BenutzerOberflächen dran anschließen.

    Das ist im Grunde alles, also:
    Dataset: Mehr Modelliermöglichkeiten, Unterstützung von Databinding
    Serialisierung: auch schön, aber weniger Modellierungsmöglichkeiten, kein Databinding

    Serialisierung ist für OOP-Programmierer einfacher mit umzugehen, er muss sich dafür kein Verständnis relationaler Zusammenhänge erarbeiten. Also bei Serialisierung lernst du im Grunde nix neues (weder Relationalität noch Databinding) - jo, dementsprechend umständlicher und eingeschränkter an Möglichkeiten isses halt.
    Aber wenn die Möglichkeiten hinreichen, vlt. ein andermal ...

    Ich weiß. Aber solch Gebinde tickt anners und ist gegenüber typDataset auch recht eingeschränkt an Möglichkeiten.

    Achso: Zu den prinzipiellen Unterschieden zählt auch noch, dass beim Dataset das Objekt im Designer erstellt wird, der den eiglichen Klassen-Code generiert.
    Bei Serialisierung muss man den KlassenCode selbst schreiben. So selbstgeschriebene Klassen können, wenn sie gut gemacht sind, wesentlich smarter sein.
    Was der Dataset-Designer generiert, enthält immer einen Riesen-Overhead an Möglichkeiten, die kaum jemals wirklcih alle genutzt werden.
    Andererseits ist im generierten Code an so gut wie alles gedacht - bei selbstgeschriebenem zeigt sich oft oder gar meist, dass Features wünschenswert wären, die selbst zu schreiben irrsinnig aufwändig wäre.
    Also für vollständig durchdachte, einfache Konzepte kann man Serialisierung in Betracht ziehen, v.a., wenn man Dataset noch nicht gelernt hat.
    Aber wenn man Dataset "kann", braucht man Serialisierung nur noch in ausgesprochenen Ausnahmefällen.

    Hallo,

    Endschuldigung aber in einen endscheidenden Punkt muss ich leider wiedersprechen, die Datenbindung ist auch mit einen Serialisierten Object möglich. Dazu muss man eine Object Datenquelle schreiben wie ich es z.B. in ASP.NET für den umgang mit der Facebook-API gemacht habe, Parameter müssen dort alerdings irgendwie (z.B. über die Session) übergeben werden (z.B. id und oder AccesToken bei der fb api jetzt^^). Aber eine Object Datenquelle (ist ja eigentlich nur ein Warper damit Peudo Daten auf Serialisierungen und anderen Object Quellen) in Datasets weiter verarbeitet werden können oder habe ich den Sinn hinter Object Datenquellen irgendwie leicht falsch verstanden?

    ErfinderDesRades schrieb:

    Ich weiß. Aber solch Gebinde tickt anners und ist gegenüber typDataset auch recht eingeschränkt an Möglichkeiten.
    Wie gesagt: Wenn Serialisierung für deine Anforderung hinreicht, und du dich damit auskennst, und nichts neues lernen möchtest, dann mach doch mit Serialisierung.
    Vlt. kommst du ja ein andermal auf Dataset zurück - (und vlt auch nicht)...

    Achja, und manchmal ist Serialisierung halt auch einfach das Mittel der Wahl: Die Facebook-Api macht offensichtlich serialisierte Objekt verfügbar, da kann ich mit meine Datasetse natürlich auffm Blocksberg tanzen gehn, es wird nix nützen :evil:

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Hallo,

    Nicht ganz, wohl er das Gegenteil, ich bin sehr daran Interessiert was neues zu lernen, deswegen möchte ich mich damit ja beschäftigen.

    Hintergrund der ganzen Sache ist dein TCP-Asynnc Server Tutorial. Mir geht es jetzt darum eine Art Datenbanck für Metainformationen abzulegen.

    Serialisierung nutze ich um mir ein einfaches Netzwerk Protocol zu erstellen was ich Theoretisch mit belibigen Formatern (Bin, XML, JSON, usw...) realisieren kann.

    Beim den Daten wird es wesendlich Interesanter den diese sollchen in einer SQL-Compact Datenbanck gespeichert werden. Der Server soll eigentlich nichts weiter tun als API,s anzuzapfen (von cex.io^^), und die erhaltenen Daten verarbeiten (Kurse rechenen, usw...) und bei Client Verbindung an denn Client übertragen.

    Da dieses Programm aber eine gewissen eigenintelienz benötigt muss ich mit Daten Daten rbeiten, und da möchte ich auf jedenfall mir informieren wie man "es richtig" macht.

    LG, Herbrich

    wie "es richtig" geht, weißich auch nicht, an Schlagworten fällt mir spontan ein: TLS, Soap, WCF, Remoting, wobei ich sagen muss, von WCF und Soap habich kein Plan.

    Und ich weiß, dass ein Dataset natürlich hervorragend mit einer DB kommuniziert - bei serialisierten Objekten musste da sicher einiges mehr an Umfüll-Code schreiben.

    WCF und SOAP sind untern Strich ja das gleiche, wo bei du sicherlich nicht SOAP meinst sondern WebDienste in klassischen sinne. Die sind nur schwer für "Realtime" zu inplementieren da sie einen miesen overhead haben, klar kann man SOAP auch direkt über TCP übertragen (Standart Fall ist ja eigentlich SoH (Soap over HTTP). Remoting weiß ich nicht, habe es mir angesehen und es nutzt auch iwelche WCF dienste (also un unkehr Schluß SOAP mit RPC-Calls).

    Ich will eine eigene performance Netzwerk Kommunikation ermöglichen die Optional TLS/SSL anbietet damit ich dass ganze auch über's Internet laufen lassen kann.

    Die Datenbanck hingegen, da will ich den Möglichst besten Weg gehen, jetzt habe ich doch noch mal die Frage was eine LINQ ro SQL Klasse ist, ist es nicht auch eine Art Modernes Dataset??

    LG, Herbrich

    Hallo,

    Kann ich LinqToSQL Aber trotzdem weiter verwenden, oder muss es ein Dataset sein, weil da finde ich das Abfragen genau so wie das einfügen von Datan sehr einfach.

    Zur I-Net übertragung, da werden nicht die OR-Objecte übertragen sondern nur die Daten in ihren endsprechenden Protocol.+

    LG, Herbrich

Facebook
Telefonspende