Announcement

Collapse
No announcement yet.

Problem mit Datenbindung

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Problem mit Datenbindung

    Hallo,

    ich habe ein Problem mit der Datenbindung von Klassen an DataGridViews. Vielleicht kann mir jemand einen Tipp geben, wie ich das Problem lösen kann.

    Angenommen ich habe eine Klasse mit den public Properties P1, P2, P3. Zu dieser Klasse erzeuge ich mir über das Datenquellen-Fenster in Visual Studio eine Datenquelle und ziehe diese dann auf eine Form. Das Studio legt mir neben der BindingSource auf der Form ein DataGridView an, das die Spalten P1, P2 und P3 hat. Soweit so gut.

    Nun habe ich eine zweite Klasse, die folgendermaßen aussieht:

    Code:
    public class C2
    {
      int p1;
      public int P1
      {
        get { return p1; }
        set { p1 = value; }
      }
    
      C3 c3;
      public C3 
      {
        get { return e; }
        set { e = value; }
      }
      public C2()
      {
         c3 = new C3();
      }
    }
    und C3 ist definiert als

    Code:
    public class C3
    {
      int p2;
      public int P2
      {
        get { return p2; }
        set { p2 = value; }
      }
      int p3;
      public int P3
      {
        get { return p3; }
        set { p3 = value; }
      }
    }
    Also die Properties P2 und P3 sind in einer zweiten Klasse zusammengefasst.

    Zur Klasse C2 erzeuge ich wieder eine Datenquelle und ziehe diese auf das Formular. Jetzt bekomme ich ein DataGrid mit den Spalten
    P1 und C3. Und hier liegt mein Problem: Ich hätte gerne wie im ersten Fall im Grid die Spalten P1, P2 und P3.

    Gibt es eine einfache Möglichkeit (zum Beispiel durch angeben von Attributen) dies zu erreichen? Ich sehe es einfach nicht.

    Viele Grüße
    Mike

  • #2
    Hallo,

    Code:
    ...einen Tipp geben, wie ich das Problem lösen kann.
    der "Fehler" besteht darin, eigene Klassen zu schreiben ;-)

    Wenn im Data Source Configuration Wizard der Eintrag Object ausgewählt wird, kann ein in einer beliebigen Assembly untergebrachtes typisiertes DataSet ausgewählt werden. Dort lassen sich beliebig viele DataTable-Instanzen unterbringen, die über DataRelation-Instanzen verbunden werden können. Wenn dann in der Benutzeroberfläche (DataGridView) eine völlig andere Sichtweise auf die Daten benötigt wird (d.h. im DataGridView sollen Spalten angezeigt werden, die aus verschiedenen DataTable-Instanzen im DataSet stammen), können diese über die DataTable-Eigenschaft Expression über Parent.Spaltenname etc. nur für die Anzeige eingemischt werden.

    Wenn man auf das typisierte Dataset verzichtet, aber bei der Datenbindung den gleichen Komfort haben möchte, muss man auch die komplette Funktionalität in denen eigenen Klassen implementieren. Da dieser Nachbau wohl weniger sinnvoll ist, führt das Veröffentlichen der benötigten Member in der Klasse C2 wohl eher zu Ziel.

    Comment


    • #3
      Hallo Herr Kosch,

      vielen Dank für Ihre Antwort.

      >> der "Fehler" besteht darin, eigene Klassen zu schreiben ;-)
      Dummerweise sind die Klassen schon da und Datasets kann ich an dieser Stelle schon aus Performancegründen nicht gebrauchen.

      >> Wenn man auf das typisierte Dataset verzichtet, aber bei der Datenbindung den gleichen Komfort haben möchte, muss man auch die komplette Funktionalität in denen eigenen Klassen implementieren.
      Ok aber zu viel Aufwand, zumal ich die Anzeige in einem Grid ja eigentlich nur zu Testzwecken benötige.

      >> Da dieser Nachbau wohl weniger sinnvoll ist, führt das Veröffentlichen der benötigten Member in der Klasse C2 wohl eher zu Ziel.
      Ja, das ist eine gute Idee. Zwar etwas Schreibarbeit, für jeden Member aus C3 ein ReadOnly-Property in C2 zu bauen (die echten Klassen sind halt ein bisschen größer) aber ich erreiche das was ich möchte.

      Nochmal vielen Dank
      Mike

      Comment


      • #4
        Hallo,

        ...Datasets kann ich an dieser Stelle schon aus Performancegründen nicht gebrauchen.
        beim .NET Framework 1.x war das in der Tat ein Grund, aber ab .NET 2.0 nicht mehr (Microsoft hat das Fundament der DataTable-Klasse neu geschrieben). Im MSDN Magazin 11.2005 wurde ein Testprogramm veröffentlicht, dass bei 1.000.000 Zugriffen die Ergebnisse 1831 Sekunden (.NET 1.x) zu 23 Sekunden (.NET 2.0) liefert.

        .. zumal ich die Anzeige in einem Grid ja eigentlich nur zu Testzwecken benötige.
        In diesem Fall würde ich ein typisiertes DataSet als "In-Memory-Tabelle" im DataSet-Designer anlegen und die Daten der Objektinstanzen dort hinein kopieren. Wenn die Funktion sowie nur zum Test benötigt wird, ist das besser, als die Klassen im öffentlichen Teil zu ändern.

        Comment


        • #5
          Hallo Herr Kosch,

          beim .NET Framework 1.x war das in der Tat ein Grund, aber ab .NET 2.0 nicht mehr (Microsoft hat das Fundament der DataTable-Klasse neu geschrieben). Im MSDN Magazin 11.2005 wurde ein Testprogramm veröffentlicht, dass bei 1.000.000 Zugriffen die Ergebnisse 1831 Sekunden (.NET 1.x) zu 23 Sekunden (.NET 2.0) liefert.
          Das stimmt schon, aber der direkte Zugriff über Properties ist doch noch um einiges schneller. Ich schätze mal Faktor 1000. Wenn ich Zeit finde, werde ich mal einen Test machen.

          In diesem Fall würde ich ein typisiertes DataSet als "In-Memory-Tabelle" im DataSet-Designer anlegen und die Daten der Objektinstanzen dort hinein kopieren. Wenn die Funktion sowie nur zum Test benötigt wird, ist das besser, als die Klassen im öffentlichen Teil zu ändern.
          Sie haben natürlich Recht, dass man eine Klasse nicht für einen Test ändern sollte. Aber mir gefallen mittlerweile die Zugriffs-Properties besser als der "Zugriff über die Unterklasse", deshalb ist die Änderung der Klasse schon ok.

          Gruß
          Mike

          Comment

          Working...
          X