LinQ Binär Serialisieren ?

verwendetes Datenbanksystem: <Linq>

Kann man DataContext binär Serialisieren? Es befindet sich ein Typ Binär in meiner Daten Context, der ein Image enthält.

Danke

Hallo,

soweit ich weiss, kann man den DataContext garnicht sinnvoll serialisieren.

mfg serial (passender nick)

Hallo,

der DataContext repräsentiert ja nur die Datenquelle mit allem drum und dran, ist ja aber nicht diese. Wenn du sagst du hast da nen Bild drin, dann hat die Datenquelle doch dieses Bild und nicht der DataContext. Wieso willst du dann den DataContext serialisieren?

Ich hab einfach propritäre Speicherformate satt und will nicht mehr von hand Strukturen und Klassen Serialisieren. Ich will aber auch nicht mit Kanonen auf Spatzen schießen. Also keine Datenbank installieren müssen.

Ganz einfaches Beispiel: Ich arbeite an einer Software die einfach Medien wie Spiele, Videos und Bücher Katalogisieren soll und die dazugehörigen Cover. Eigentlich das Einfachste von der Welt. Aber ich will mal den alten Staub der letzten 15 Jahre abstreifen. LinQ und Anonyme Typen gehen in die richigte Richtung. Jedoch womit auffüllen? Mit einer Datenbank?

Ich glaube für meine Aufgabe bleibt einfach nur eine Access Datenbank übrig.

SQLlite ist mir zu frickelich und zu unprofessionell.

SQlite ist die am weitesten verbreitete embedded Datenbank weltweit.
Sie ist der Standard in allen Mozilla Projekten, ist die std DB von jedem IPhone und Android Handy, und in unzähligen anderen Programmen und Systemen integriert.

Vielleicht ist auch nur deine herangehensweise zu frickelig und unprofessionell.

Und zu deiner Aufgabe, das kann jeder dahergelaufene ORMapper mit Links erledigen,
egal ob LinQ2Sql, EF, NHibernate oder BLToolKit.

Es geht nicht um "eine daher gelaufene Lösung", sondern um Fortschritt. Ich suche nach einem Zwischenschritt zwischen schwerfellige und langsame Datenbanken und superschnelle starre Strukturen ( heute in Klassen verwurstet ).

Man programmiert schließlich keine 3D Engine mit einer langsamen Datenbank, sondern nutzt Strukturen. Aber der flexible Aufbau und Zugriff einer Datenbank könnte man gut auf die riesen ansammlung von Daten einer 3D Engine gebrauchen.

Ökonomie ist das Schlagwort. Ich kann von München bis Berlin mit einem kleinen Kinderrad fahren oder ich nehme einfach den ICE. C# Beinhaltet alle guten Erfahrungen aus der Programmierung der letzten 20 Jahre. Ich finde speichern und laden wird noch stiefmütterlich behandelt.

Hier mal der Datenfluss eines simplen FLOAT Wert in einem CAD Programm mit der Bezeichnung "Weight"

Datei -> Editor -> Datei -> Server -> Netzwerk -> Client -> Datei

Was auch immer ich damit meine. Der FLOAT Wert "Weight" muss überall einprogrammiert werden.

Irgendwie hast du ziemlich komische Vorstellungen.

Wie dem auch sei, schon mal was über NoSql gelesen?

Irgendwie hast du ziemlich komische Vorstellungen.

Also das ist jetzt nicht böse gemeint, aber ich arbeite in der Spielebranche und an großen 3D Simulations Programmen. Da liegt die Messlatte in Sachen Programmierung hoch. Hierbei sind überlegungen zum verbessern der Entwicklung erwünscht. Schließlich sind C# und .NET nicht einfach vom Himmel gefallen. Auch Microsoft hat aus fehlern wie MFC, Win32 SDK, ATL etc gelernt und aus den Erfahrungen .NET entwickelt/aufgesetzt.

Also wenn so jemand wie ich mal neue Dinge ausprobieren will oder nachfragt was gerade stand der dinge ist, sollte man das nicht als "komisch" bezeichnen.

Ich bin warscheinlich einfach nur im falschen Forum. Die Microsoft Newsgroups wären da vielleicht besser, wenn es die noch gibt.

Ich werde jetzt eine Access Datenbank benutzen, da die sowiso auf jedem Microsoft Betreibsystem benutzbar ist.

Hallo,

du sagst du willst was neues probieren und verwendest jetzt Access Dateien?

Solche embedded Datenbanken wie SQLite oder ähnliche sind Stand der Technik - was willst du da unbedingt anders machen? Mit NoSql wurde ja auch nen Vorschlag gemacht der grad so nen Modethema bei der Datenspeicherung ist.

Sicherlich habt ihr spezielle Anforderungen, aber grad bei so speziellen Sachen kann man nicht verlangen das es da zig allgemeingültige Lösungen gibt. Welche Datenbanken habt ihr den evaluiert wenn du zum Schluss

...schwerfellige und langsame Datenbanken ... kommst? Das ist nämlich bei weitem nicht so.

Was auch immer ich damit meine. Der FLOAT Wert "Weight" muss überall einprogrammiert werden.

Ich glaube ich verstehe, wo der Schuh drückt. Du möchtest flexible Datenstrukturen, die komfortabel, schnell und leichtgewichtig sind. Vor allem möchtest Du keine Klassen starr hinschreiben.

Das .NET Framework hat eine solche Struktur seit Version 1.0: Das DataSet. DataSets bzw. DataTables sind sehr flexibel. Trotzdem bieten sie jede Menge Komfort (z.B. Linq2DataSet) und können schnell zugregriffen werden (Schlüsselspalten werden automatisch idiziert). Serialisierung ist auch auch kein Thema. Egal ob binär oder XML.

Vergiss den starren ORM-Käse und schau Dir mal das DataSet bzw. die DataTable (beide im Namensraum System.Data) an.

Ob Du dann noch eine Embedded DB dahinter hast oder nicht, ist dem DataSet egal. Du kannst es auch ohen weiteres als Mini-DB einsetzen. Allerdings nur, wenn Du nicht mehr Daten verarbeiten willst, als in Deinen Hauptspeicher passen. Falls das nicht zutrifft, solltest Du wirklich eine Embedded DB dahinter hängen.

Vergiss Access-MDBs. Das ist doch Schrott. Ehrlich. Access als Front-End ist in bestimmten Szenarien eine feine Sache, aber niemals als Datenbanksystem!