Singleton, Serialisierung (Json, Xml) und Databinding ohne Dataset

    • VB.NET
    • .NET (FX) 4.0

      Singleton, Serialisierung (Json, Xml) und Databinding ohne Dataset

      Anbei ein Sample mit formübergreifendem Databinding.

      Singleton
      Formübergreifendes Databinding erfordert ein global zugreifbares Objekt, nur eines wohlgemerkt. Diese Singularität kann man zB mittels eines Singleton sicherstellen - hier die wohl aller-einfachste Ausführung:

      VB.NET-Quellcode

      1. Public Class Repository
      2. Public Shared ReadOnly Instance As New Repository
      3. Private Sub New()
      4. End Sub
      5. '...
      der Private Konstruktor verhindert, dass von aussen ein Repository erstellt werden kann, und die einzige Instanz dieser Klasse ist nun Public Shared ReadOnly - steht da ja.

      Serialisierung
      Es gibt verschiedene (konkurrierende) Produkte - die alle dasselbe machen: Sie schreiben Objekte als ByteFolge in einen Stream, entweder um ihn zu verschicken, oft im Falle FileStream wird ja an eine Datei "geschickt"- anders gesagt: Das Objekt wird abgespeichert.
      Jo, ich hab mal mit ein paar Varianten herum-experimentiert, und dann für die, die ohne externe Dll funzen, eine SerialisationHelper-Klasse geschrieben, da kann man auch mit dem unterschiedliche Verhalten bischen experimentieren.
      zweimal Json, einmal Xml

      VB.NET-Quellcode

      1. Imports System.Text
      2. Imports System.IO
      3. Imports System.Runtime.Serialization.Json
      4. Imports System.Xml.Serialization
      6. Public Class SerialisationHelper
      7. Public Shared Function FromJContractString(Of T)(input As String) As T
      8. Dim ser = New DataContractJsonSerializer(GetType(T))
      9. Using ms As New MemoryStream(Encoding.UTF8.GetBytes(input))
      10. Return DirectCast(ser.ReadObject(ms), T)
      11. End Using
      12. End Function
      13. Public Shared Function ToJContractString(Of T)(input As Object) As String
      14. Using ms As New MemoryStream()
      15. Dim ser As New DataContractJsonSerializer(GetType(T))
      16. ser.WriteObject(ms, input)
      17. ms.Position = 0
      18. Using sr As New StreamReader(ms)
      19. Return sr.ReadToEnd()
      20. End Using
      21. End Using
      22. End Function
      24. Public Shared Function FromJScriptString(Of T)(ByVal input As String) As T
      25. Dim ser As New System.Web.Script.Serialization.JavaScriptSerializer
      26. Return ser.Deserialize(Of T)(input)
      27. End Function
      28. Public Shared Function ToJScriptString(Of T)(ByVal input As Object) As String
      29. Dim ser As New System.Web.Script.Serialization.JavaScriptSerializer
      30. Return ser.Serialize(input)
      31. End Function
      33. Public Shared Function FromXmlString(Of T)(ByVal input As String) As T
      34. Dim ser = New XmlSerializer(GetType(T))
      35. Using ms As New MemoryStream(Encoding.UTF8.GetBytes(input))
      36. Return DirectCast(ser.Deserialize(ms), T)
      37. End Using
      38. End Function
      39. Public Shared Function ToXmlString(Of T)(ByVal input As Object) As String
      40. Using ms As New MemoryStream()
      41. Dim ser As New XmlSerializer(GetType(T))
      42. ser.Serialize(ms, input)
      43. ms.Position = 0
      44. Using sr As New StreamReader(ms)
      45. Return sr.ReadToEnd()
      46. End Using
      47. End Using
      48. End Function
      49. End Class
      Die Unterschiede betreffen gewisse Attribute, die gesetzt werden können oder müssen - will ich hier garnet drauf eingehen.
      Der Vollständigkeit halber erwähne ich noch die Serialisierung mittm BinaryFormatter, dessen Ausgabe ist nicht menschen-lesbar, aber dafür kann er manche Klassen noch serialisieren, die menschenlesbar nicht serialisierbar sind (zB. Fonts).

      Serialisierung-Persistenz
      Obiger Code serialisiert nicht in Bytes, sondern wandelt diese gleich wieder nach String um, damit Json/Xml-Code in der Textbox begutachtet werden kann. Das hat nur Demonstrations-Wert - normalerweise serialisiert man zu Streams, meist FileStreams - Abspeichern halt.
      Deshalb hab ich ein Extension-Modul gemacht, für Stream und FileInfo, die entweder mit einem BinaryFormatter oder mit XmlSerializer persistierbar sind (Json wäre natürlich ebensogut möglich):
      Serialisierungs-Extensions

      VB.NET-Quellcode

      1. Public Module SystemIoX
      3. <Extension()> _
      4. Public Sub SerializeXml(fi As FileInfo, obj As Object)
      5. ' Achtung! FileInfo.OpenWrite ist ungeeignet, denn es erneuert nicht unbedingt die ganze Datei
      6. Using strm = fi.Open(FileMode.Create)
      7. strm.SerializeXml(obj)
      8. End Using
      9. End Sub
      10. <Extension()> _
      11. Public Sub SerializeXml(strm As Stream, obj As Object)
      12. Call (New XmlSerializer(obj.GetType)).Serialize(strm, obj)
      13. End Sub
      14. <Extension()> _
      15. Public Function DeserializeXml(Of T)(fi As FileInfo) As T
      16. Using strm = fi.OpenRead
      17. Return strm.DeserializeXml(Of T)()
      18. End Using
      19. End Function
      20. <Extension()> _
      21. Public Function DeserializeXml(Of T)(strm As Stream) As T
      22. Return DirectCast((New XmlSerializer(GetType(T))).Deserialize(strm), T)
      23. End Function
      25. <Extension()> _
      26. Public Sub Serialize(fi As FileInfo, obj As Object)
      27. ' Achtung! FileInfo.OpenWrite ist ungeeignet, denn es erneuert nicht unbedingt die ganze Datei
      28. Using strm = fi.Open(FileMode.Create)
      29. strm.Serialize(obj)
      30. End Using
      31. End Sub
      32. <Extension()> _
      33. Public Sub Serialize(strm As Stream, obj As Object)
      34. Call (New Runtime.Serialization.Formatters.Binary.BinaryFormatter).Serialize(strm, obj)
      35. End Sub
      36. <Extension()> _
      37. Public Function Deserialize(Of T)(fi As FileInfo) As T
      38. Using strm = fi.OpenRead
      39. Return strm.Deserialize(Of T)()
      40. End Using
      41. End Function
      42. <Extension()> _
      43. Public Function Deserialize(Of T)(strm As Stream) As T
      44. Return DirectCast((New Runtime.Serialization.Formatters.Binary.BinaryFormatter).Deserialize(strm), T)
      45. End Function
      47. End Module
      Aufruf-Beispiel (im Repository):

      VB.NET-Quellcode

      1. Private _DataFile As New FileInfo("..\..\Autos.Xml")
      3. Public Sub Save()
      4. _DataFile.SerializeXml(_Autos)
      5. End Sub
      6. Public Sub Load()
      7. Autos = _DataFile.DeserializeXml(Of BindingList(Of Auto))()
      8. End Sub
      Diese Extensions sind also der wiederverwendbarste Code dieses Tutorials: sie machen Speichern/Laden zum Einzeiler.

      Databinding
      Meist denkt man bei Databinding an typisierte Datasets oder Entity-Framework, aber das ist garnet zwingend.
      Grundsätzlich kann an jede Property gebunden werden (wohlgemerkt: nur an Properties - nicht an Felder).
      INotifyPropertyChanged
      Falls die Properties den INotifyPropertyChanged-Benachrichtigungsmechanismus unterstützen kann Binding auch bidirektional erfolgen, also nicht nur das Control ändert die Property, sondern wenn man codeseitig die Property ändert, wird (durch feuern des PropertyChanged-Events) automatisch auch das Control geupdatet.
      Da dieses Feature in großem Umfang genutzt wird, empfiehlt es sich, sich eine Basisklasse zu machen, die INotifypropertyChanged implementiert, und dann können Datenklassen davon erben und das Feature quasi gemeinsam nutzen.
      Minimal-Version solche einer Klasse wäre etwa so:

      VB.NET-Quellcode

      1. Public Class DataBase : Implements INotifyPropertyChanged
      2. Public Event PropertyChanged(sender As Object, e As PropertyChangedEventArgs) Implements INotifyPropertyChanged.PropertyChanged
      3. Public Sub RaisePropertyChanged(propName As String)
      4. RaiseEvent PropertyChanged(Me, New PropertyChangedEventArgs(propName))
      5. End Sub
      6. End Class
      aber meist gestaltet man das aufwändiger, um eine komfortablere Benutzung zu erreichen.
      Jedenfalls spricht nichts dagegen, INotifypropertyChanged-Klassen zu serialisieren, also kein Grund wegen des einen (Persistenz) auf das andere (Databinding) zu verzichten.

      Designer-Unterstützung
      Und auch auf Designer-Unterstützung braucht nicht verzichtet werden, man muss dem Projekt nur die Klassen, deren Bindings man im FormDesigner gestalten möchte als Datasource bekannt machen.
      Dazu klickst man einfach im Datenfenster auf "Datenquelle hinzufügen", und fügt eine Datenquelle hinzu, und zwar eine Objekt-Datenquelle:
      ... ...
      (Wie man sieht, gehts im Sample um Autos)
      Zu beachten auch der voreingestellte Haken bei "Hide system assemblies". Weil wenn man den uncheckt, dann kann man ebensogut auch alle Framework-Klassen Designer-Databinding verfügbar machen.
      Hier ein Video, wo das auf FileInfo angewandt wird: Keine Strings in die File-Listbox!

      Jo, also hat man seine eigenen serialisierbaren Klassen Designer-Databinding verfügbar gemacht, so steht einem vom Prinzip her alles offen, was in vier Views-Videos an Möglichkeiten gezeigt ist. (Ich empfehle jedem, der mit den Gestaltungs-Möglichkeiten bezüglich Databinding nicht sehr vertraut ist, die beiden Links auch aufzusuchen, und sich die kurzen Videos mal zu Gemüte zu führen).

      Aber halt nur im Prinzip, denn eigene Datenmodell-Klassen unterstützen nur hierarchische Modellierung, keine relationale.
      Daher entfallen der JoiningView und folglich auch der m:n-View, aber immerhin Parent-Child und DetailView machen überhaupt kein Problem:

      (Sorry, das Sample ist ursprünglich zum Serialisierung testen gewesen, die DataBinderei ist nachträglich drangepatcht, daher siehts bischen wirr aus :saint: ).
      Aber erkennbar oben ein gebundenes PropertyGrid, unten links die (Parent-)Liste der Autos (es sind nur 2), Mitte der DetailView des Auto-Nummernschildes, und rechts der ChildView (halt die Räder - ja, ist nicht ganz so sinnvoll ;) )
      Im DetailView auch die Buttons um den Unterschied aufzuzeigen, wenn NotifyPropertyChanged gefeuert wird, und wenn nicht.

      BindingList(Of T)
      Wie eingangs erwähnt ist die Datenhaltung aus dem Form herausgenommen und in ein Singleton-Repository verlagert, und so kann man mehrere solcher Forms anzeigen, und alle sind an dieselben Daten gebunden.
      Dabei ist zu beachten, dass nicht List(Of Auto) genommen wird, sondern BindingList(Of Auto).
      Weil BindingList(Of T) feuert das IListChanged-Event, und benachrichtigt so das Gui von Zufügungen und Löschungen.
      Bei Verwendung der einfacherern List(Of T) käme es beim übergreifenden Databinding zu Inkonsistenzen, wenn im einen Datagridview ein Auto gelöscht wird, aber das andere Datagridview weiß noch nichts davon.

      Zusammenfassung
      Serialisierung kann man als stark abgespeckte Form von Persistenz ansehen, verglichen mit den auf relationale Datenverarbeitung ausgelegten Technologien EntityFramework / typisiertes Dataset.
      Serialisierung kommt dabei ohne umfangreichen generierten Code aus, und braucht auch keine Datenbank, verzichtet aber neben der Relationalität auch auf weitere Funktionalität, welche bei klassischer Datenverarbeitungs von Haus aus bereitsteht: Filtern, Sortieren, Canceln von Edit-Vorgängen, Validieren. (also der Verzicht ist nicht generell, aber man muss jeweils besondere Vorkehrungen treffen, mehr oder weniger aufwändig)

      Hingegen ein entscheidender Vorzug kann sein die Kompatiblität zu anderen Plattformen.

      So oder so: auf Databinding als Architektur-Paradigma braucht nicht verzichtet werden - weder zur Laufzeit noch zur Designzeit :D
      Dateien

      • JsonTests.zip

        (22,94 kB, 275 mal heruntergeladen, zuletzt: )

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

    Facebook
    Telefonspende