die vier Views auf Video

    • VB.NET

    Es gibt 6 Antworten in diesem Thema. Der letzte Beitrag () ist von DMO.

      die vier Views auf Video

      So, weil ich allmählich mit utube besser klar komme, habich meine 4-Views-Theorie mal in Videos veranschaulicht.

      Vorraussetzung zum Verständnis ist ein Verständnis der relationalen Datenmodellierung, also was bedeutet Beziehung (alias "Relation"), was ist eine 1:n-Relation, was eine m:n-Relation, und warum ist relationale Datenmodellierung so viel toller als wenn man einfach Objekte schafft, die selbst wieder Listen weiterer Objekte enthalten.

      Vier-Views-Theorie
      naja, ich unterscheide 4 grundlegende Typen, wie man komplexe Daten präsentieren kann (also anzeigen + der User kann was damit tun):
      1. DetailView: Labels, Text-/Check-boxen, DateTimePicker etc zeigen/editieren Werte eines zuvor ausgewählten Datensatzes (klassische "Eingabe-Maske")
      2. ParentChild-View: links wird aus der ParentTable ein Datensatz ausgewählt, und rechts zeigt eine zweite Tabellen-Ansicht alle damit verknüpften Child-Datensätze
      3. JoiningView: ComboboxColumns holen Werte übergeordnet verknüpfter Tabellen in eine TabellenAnsicht hinein.
      4. m:n - View: Kombination ParentChild - JoiningView: links die ParentTable, rechts Childrows. Mittels Comboboxen werden Werte einer anderen übergeordneten Tabelle hineingeholt.
        Sodass in Summa die indirekte Beziehung zweier übergeordneter Tabellen sichtbar wird - ihre m:n-Relation.
      Den Plain- oder Raw-View, der einfach die Tabellen anzeigt wie sie sind, zähle ich nicht zu den 4 Views, weil ist zu primitiv.
      Jedenfalls wesentlich an den Views ist auch, dass man sie nach Belieben und Erfordernis miteinander kombiniert, und damit eine unerhörte Vielfalt an Präsentations-Möglichkeiten erhält.

      Beispiel-Datenmodell
      Man denke an ein Kaufhaus - extrem verkürzt: es gibt Artikel, ArtikelKategorien und Lieferanten - mehr nicht.
      Das Modell ist auch schnell notiert:
      Category -> Article <- Deliverer

      oder als Dataset-Bildle:

      Artikel ist sowohl den Kategorien als auch den Lieferanten untergeordnet: eine Kategorie enthält viele Artikel, ein Lieferant liefert viele Artikel.
      Und andersrum betrachtet: jeder Artikel verweist mittels ForeignKey auf genau eine Kategorie, und auf genau einen Lieferanten.
      Also zwei 1:n-Relationen mit gemeinsamer untergeordneter Tabelle, und sowas ist inne Datenbänkerei halt als m:n-Relation bekannt (eine Kategorie enthält Artikel vieler Lieferanten, und ein Lieferant liefert Artikel vieler Kategorien)

      Wie gesagt: Wer diesen Begrifflichkeiten (1:n - m:n - Relation) nicht folgen kann: Relationale Datenmodellierung
      Andernfalls mögen die folgenden Filmle eine vielleicht beeindruckende Zielvorstellung und Motivation geben. Aber praxisrelevant, also dass man die gezeigten Features in eigenen Projekten dienstbar hat, ist das erst, wenn das mit den Relationen richtig verstanden ist, weil darauf baut es auf.
      Übrigens jede nicht-triviale Sql-Datenbank baut ebenfalls darauf auf.

      Die Filme

      Film I - Datamodel Hier wird das Datenmodell aufgesetzt, und auch die Datengenerier-Methode angedeutet, die dieses Modell adäquat füllt, insbesondere die Artikel-Table, (nämlich aus zwei sich teilweise überschneidenden Lieferanten- und Kategorie-Gruppen).
      Die Generiererei ist eiglich zu kompliziert, ums im Film gleich zu kapieren, aber sie ist im Code-Download drinne, und ist mir wichtig zu zeigen, dass das typisierte Dataset über einen Haufen speziell generierte Methoden verfügt, mit denen man eigentlich jeden Standard-Zugriff in streng typisierter Manier ausführen kann - natürlich auch das Adden von neu generierten typisierten DataRows.
      Also beim Zugriff aufs Dataset willich nix sehen mit: myDataset.BlablaTable.Rows(CInt(grottenRow("HoffeEsGibtDieseSpalte")) :cursing:
      odersowas (achtung - Beispiel ausse Praxis):

      VB.NET-Quellcode

      1. DataSet1.Tables("Dingsbumsdaten").Rows(DingsbumsdatenDatagridView.SelectedCell.RowIndex) = CInt(DingsbumsdatenDatagridView.Rows(dgvDingsbumsdaten.CurrentCell.RowIndex).Cells(0).Value))
      Also gugget den typisierten Zugriff im SampleCode an, und guckt die 3 Tabellen auch im ObjectBrowser an, was da alles an typisierten Kram drinnesteckt, sodass man die untypisierten Typen Dataset, DataTable, DataRow nie nie wieder benutzen braucht - also wo As DataRow im Code auftaucht - da läuft schon was falsch!
      Wir haben ArticleRows, CategoryRows, DelivererRows in unserem Dataset, auf die untypisierte Basisklasse DataRow können und sollten wir vollständig verzichten!

      Film II - RawView erstellt eine erste Roh-Ansicht aller 3 Tabellen, ohne jede Fisematente. Sowas braucht man eiglich immer, um schnell zu gugge, ob Daten da sind, oder um halt mal welche eingeben zu können.

      Film III - JoiningView zeigt endlich den ersten der 4 Views, nämlich den JoiningView, also ein Article-DatagridView, bei dem ComboboxColumns Werte der übergeordneten Tabellen mit "hinein-joinen" (nämlich Category.Name und Deliverer.Name)
      Der Name "JoiningView" ist in Analogie zur Sql-InnerJoin-Abfrage gewählt, denn ein JoiningView zeigt genau die Daten an, die auch ein Sql-InnerJoin über mehrere Tabellen anliefern würde.
      Er leistet aber wesentlich mehr, denn er ermöglicht dem User, Änderungen vorzunehmen und zurückzuspeichern - eine Option, die beim Sql-Innerjoin prinzipiell ausgeschlossen ist.

      Film IV - DetailView zeigt eine schlichte Liste der Artikel(-Namen), und man kann einen Artikel auswählen, und bekommt all seine Properties in ausführlichen Einzel-Controls präsentiert.
      Der hier gezeigte DetailView geht aber über einen schlichten DetailView hinaus, denn er enthält auch einen Joining-Part, nämlich Comboboxen, die (wieder) Category.Name und Deliverer.Name mit-präsentieren.
      Es handelt sich hier also um einen kombinierten View, und das ist ebenfalls Kern-Aussage der 4 View-Theorie, nämlich dass die vier Grundtypen beliebig kombinierbar sind.

      Film V - ParentChild-View zeigt links alle Kategorien, und rechts alle Artikel, die der links gewählten Kategorie angehören.
      Obwohl sehr einfach zusammengeklickst, beeindruckt dieser View doch mehr als ein Joining-View, weil über das Databinding werden immer alle angezeigten Artikel ausgetauscht, wenn man eine annere Category wählt.

      FilmVI - m:n-View - habe ich gleich in beide Richtungen implementiert: Einmal kannman eine Kategorie wählen, und sieht alle Artikel, inklusive Lieferant.
      Beim View in Gegenrichtung kann man dann einen Lieferanten wählen, und sieht alle Artikel, die er liefert, inklusive ihrer jeweiligen Kategorie.
      Son m:n-View kombiniert also den ParentChildView (Film V) mittm JoiningView (Film III).



      Weiterführende Links
      • Im hiesigen Tut wird ja nur Designer-Arbeit an Datenmodell und Präsentation gezeigt. Laden und Speichern und Datenverarbeitung in typisierter Manier findet sich auf Daten laden, speichern, verarbeiten
      • Zu den sehr mächtigen Möglichkeiten der BindingSource-Klasse findet sich auf DataExpressions so allerlei.
      • Auf englisch habe ich eine 3-teilige Artikel-Reihe verzapft, die einen großen Bogen spannt: relationalen Grundlagen, Design-Prinzipien, Dataset-Designer, Databinding, ObjectBrowser bis hin zu einem Beispiel nicht-trivialer Daten-Verarbeitung und -Präsentation.
        Was hier also eher schlaglicht-artig in Filmen kurz vorgeturnt wird, ist dort in einer zusammenhängenden Linie behandelt, gründlicher, und mit mehr Hintergrund.
        Würde mich auch freuen, wenns der eine oder andere up-rated - das Code-Project-Rating-System hat großen Einfluss darauf, wieviel Beachtung einem Artikel widerfährt.



      Hier die Sample-Solution der Videos als Download:
      (Übrigens ist mein Englisch falsch: "Lieferant" heißt "supplier", nicht "deliverer" - also macht das blos nicht nach!)
      Dateien
      • FourViews.zip

        (123,63 kB, 1.253 mal heruntergeladen, zuletzt: )

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

      Inspektion des generierten Zeugs, coden in typisierter Manier, und noch paar Design- und Layout-Tricks


      Film VII - Inspection: Was haben Dataset-Designer und Form-Designer eigentlich generiert?
      Wichtig! Ist man nicht imstande, sein typisiertes Dataset im ObjectBrowser zu untersuchen, oder nachzugucken, wie der FormDesigner Bindings und BindingSources konfiguriert hat, für die verschiedenen Views, dann kann man schlicht nicht programmieren 8| . Weil den Anwendungs-Prototyp, den man sich zusammenklickst, muss man natürlich verstehen, modifizieren und drauf aufbauen, dass eine wirkliche Anwendung draus wird.

      Film VIII - Coden in typisierter Manier: Typisierung stellt geniale Properties und Methoden bereit, mit Intellisense- und Compiler-Unterstützung - man muß sie aber auch benutzen - andernfalls codet man Müll.
      Bezeichnend ist, dass die Demonstration wie mans nicht macht, im Video mehr Raum einnimmt, als wie mans macht. Grund ist, dasses eben einfacher ist, wenn mans richtig macht :D
      Nämlich bis 00:59 ist die Aufgabe vorgestellt, von 01:00 - 07:59 werden die Nachteile untypisierten Code-Horrors auseinandergenommen, und erst ab 08:00 wird kurz gezeigt, wies richtig muss.
      Trotzdem auch den CodeHorror angucken - es gibt glaub nicht einen Programmierer, der von Anfang an bereits gänzlich uninfiziert war von der untypisierten Programmier-Seuche. Und anders als natürliche Krankheiten heilen Programmier-Seuchen nicht von selbst, sondern man muss die Krankheit scharf ins Auge fassen - dann verschwindet sie ;)

      Film IX - Layout und Styling: ein Teil der Einstellmöglichkeiten am Datagridview. Ausserdem die Dokumentengliederung, ein recht unbekanntes, aber sehr nützliches Instrument, um komplexe Layouts zu modifizieren

      Film X - selbst Bindings setzen: Bisher wurden Bindings vorwiegend beim Ziehen aus dem Datenfenster generiert - hier jetzt, wie man auch Combobox, Label, DateTimePicker, NumericUpdown binden kann, entweder per SmartTag oder per Eigenschaften-Fenster

      (Source in Post#1)

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

      Migration von DatasetOnly-Anwendungen auf beliebige Datenbank-Anwendungen

      FilmXI - Migration DatasetOnly->Datenbank
      Die bisher gezeigten Filme beschäftigen sich ja ausschließlich mit der (üblicherweise verkannten) Hauptsache, nämlich der Entwicklung von an typDatasets gebundenen Oberflächen.
      Persistiert wurde einfach in eine Xml-Datei (was bis weit über 20000 Datensätze vollkommen ausreicht).
      FilmXI liefert nun die Nebensache nach, die fast immer für die Hauptsache gehalten wird: nämlich wie man ggfs. die xml-Datei als Daten-Senke ersetzt durch eine DB.
      Dafür hab ich das Tool "DbGenerator" gebastelt, dem man die .xsd-Datei (nicht die .xml!) des typisierten Datasets angibt sowie den Connectionstring einer beliebigen DB, und es legt per Sql-Commands in der DB genau die Tabellen an, die es als DataTables aus der .xsd ausliest :D

      Wie gesagt: Ich empfehle jedem, diese Migration möglichst weit hintan-zustellen, oder auch ganz bleiben zu lassen, wegen Flexiblität und Portabilität: Denn je weniger Kram man sich ans Bein bindet, desto leichter kommt man voran. Und eine Xml-Datei kann man zB. problemlos verschicken, eine MySql-DB nicht.
      Aber Einsteiger in die Thematik wirds auf jeden Fall beruhigen, zu sehen, dass man jederzeit binnen 5 Minuten eine zum Dataset passende DB aufsetzen kann.

      Achso: Wenn man die Datenbank hat, benutzt man am besten meine DbExtensions für den Hin-Her-Datenfluss zwischen Dataset und Db

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

      Nicht das ich deine Tuts nicht schätze. Mit Sicherheit sind diese Videos auch von einer hohen Qualität. Und du vermutest sicher gerade ein Aber. Damit wirst du am Ende auch Recht haben.

      Was man mit deiner Methode erreicht wird, ist eine Programmierung eines Programmierers. Leider erhält man auch die Visualisierung eines Programmierers. Das Ergebnis ist längst bekannt. Man kann es sehen in der Firma SAP. Zwar zählt diese Firma zu den Top Firmen in der Welt, aber auch ihre GUI zählt zu den Top Flops dieser Welt. Es gibt eigentlich nichts was SAP nicht kann. Aber was SAP nicht kann, ist die Visualisierung von Daten. Du hast in diesem Beispiel 3 Tabellen zur Schau voran gestellt. Was ist wenn es selbst für kleine Projekte schon weit mehr werden? Hier muss der Datenbankentwickler auch die GUI gestalten, denn kein Grafikdesigner wird sich hinstellen und in GRIDS und Textboxen bzw. Comboboxen arbeiten. Er wird es auch nicht verstehen und er wird es Nice to have abstempeln. Alleine die Usability wird darunter unter gehen und nur ??? auf den Gesichtern der User zurück lassen.

      Natürlich hat die von MS geschaffene Option ihren Scharm. Man schreibt so gut wie keinen Code mehr. Selbst die DB wirkt als objektorientierte Anwendung. Leider geht dabei die Usability den Bach herunter und wirft zusätzliche Fragen auf.
      1. Darf denn jetzt jeder Hans Daten ändern?
      2. Wie gestalte ich die Zugriffsrechte?
      3. Sind diese alleine über den DB Server realisierbar?
      4. Sind diese in Teilbereichen einzuschränken?
      5. Können hier Überschneidungen stattfinden?
      6. Kann ich dies evtl. über StoredProcedures abfedern?
      7. Wie müssen die Trigger gestaltet werden?
      8. Ist bei den Tabellen Cascading immer sinnvoll?
      9. Wie verhindere ich Cascading, wenn es nicht sinnvoll ist und wie schränke ich es ggf. ein bzw. lasse es ggf. zu?

      Als Beispiel eine mit Absicht nicht wirklich lesbare DB

      Tuts können immer nur ein Einstieg sein. Die eigliche DB-Programmierung fängt erst danach an.
      Was ich hier vorstelle ist nur die basic CRUD - Funktionalität, und anwendungs-spezifisch muss man natürlich Rechte einschränken, Daten-Abruf optimieren, Business-Logik einbauen, Benutzerführung, und auch listigere Oberflächen gestalten, als das hier gezeigte Standard-Inventar.
      All diese Dinge (und weitere) kann man auf dem gezeigten Ansatz aufbauen, aber erstmal muss man ihn beherrschen.

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

      Hallo,

      es sind in der Tat hervorragende Tutorials. Hut ab, vor so viel Fleiß.

      Im Film "view Views (VII) wird ausführlich erläutert, wie die Tabellenviews aufgebaut sind. Es wird auch angegeben, dass es auch eingeschachtelte Tabellen gibt. Beispiel In der Tabelle Category gibt es ein FEld "Artikel" welches auf die Tabelle "Artikel" verweist, um nur die Artikel mit einer ausgewählten Category-ID anzeigen zu lassen.

      Bei einem Test habe ich nun eine neue Tabelle angelegt, bspw. CatProperty, welches weitere Informationen zu einer Category enthalten soll. Es wurde auche ine elation hergestellt. Es wurd alerdings kein neues Feld in der Tabelle CatProperty angelegt, in dem alle Category-Datensätze aufgelistet werden, die mit der Category übereinstimmen.

      Daher meine Frage: Wo wird denn das Spezialfeld vom Typ "Tabelle" erzeugt?