Typisierte Datasets, TableAdapters Anzahl übersichtlich halten

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 7 Antworten in diesem Thema. Der letzte Beitrag () ist von Rainman.

    Typisierte Datasets, TableAdapters Anzahl übersichtlich halten

    Guten Tag

    Grundsatzfrage

    Ich bin am Überarbeiten einer Inhouse-Datenbankanwendung und möchte diese von Access auf einen SQL-Server schieben. Das FrontEnd soll mit VB.NET erstellt werden. Bin am Suchen von Programmierlösungen, welche für uns geeignet sind. Ziel ist, verschiedene Aufgaben mit einzelnen *.exe-Anwendungen zu lösen.

    Das Arbeiten mit typisierten Datasets finde ich passend. Doch folgende Frage:

    Prinzipiell:
    Generiert ihr mit dem DataSetDesigner pro Anwendung verschiedene Datasets, gruppiert zB. nach Adressverwaltung, Artikel, etc., oder gibt es nur ein DataSet mit vielen TableAdaptern? So richtig viele, meine ich ….

    Arbeitsweise:
    Wenn eine Tabelle über verschiedene Felder und Kombinationen abgefragt wird, erstellt ihr pro Abfrage mit Hilfe des Designers je einen eigenen TableAdapter mit dem SelectString oder generiert ihr in den Forms per Code zusätzliche TableAdapter?

    Grüsse
    Danke euch.

    @VB1963
    Habe mir das mal kurz angeschaut, bin aber nicht so wirklich klar geworden damit. Muss wohl die Beispielprojekte durcharbeiten....

    @Rainman
    Hab das mal gegoogelt. Komme nicht so klar. Wie verbreitet ist denn das und für welche Applikationsgrössen wird das verwendet? Hier geht es um eine Software für einen KMU, welche sporadisch weiterentwickelt wird (OK, hat ja eigentlich keinen Einfluss...).

    Habe also einen Job für heute und morgen Abend . . .

    lollipop schrieb:

    Generiert ihr mit dem DataSetDesigner pro Anwendung verschiedene Datasets, gruppiert zB. nach Adressverwaltung, Artikel, etc., oder gibt es nur ein DataSet mit vielen TableAdaptern? So richtig viele, meine ich ….
    Ich generiere das Dataset, aber dann schmeisse ich die TableAdapter wieder runter, weil ich mir mit DbExtensions eine generische Lösung gebastelt hab, die viel leistungsfähiger ist als alle generierten TableAdapter zusammen.

    lollipop schrieb:

    Wenn eine Tabelle über verschiedene Felder und Kombinationen abgefragt wird, erstellt ihr pro Abfrage mit Hilfe des Designers je einen eigenen TableAdapter mit dem SelectString oder generiert ihr in den Forms per Code zusätzliche TableAdapter?
    Meine DbExtensions unterstützen Abfragen an miteinander verknüpfter Tabellen, also das nötige Sql können sie generieren.
    Aber man kann auch frei formulierte Where-Abschnitte zur Anwendung bringen.
    Nicht unterstützt werden "Projektionen", also es werden immer alle Felder abgefragt, weil die DataTable ja auch mit allen Feldern generiert ist. Für Projektionen, also gezielte, sparsame Spalten-Auswahl müsste man ja spezielle DataTables bereitstellen, und die wären dann auch nicht rückspeicherbar, weil ja Felder fehlen.

    lollipop schrieb:

    Wie verbreitet ist denn das und für welche Applikationsgrössen wird das verwendet?
    EF ist moderner, und ist im professionellem Bereich total verbreitet.
    Ich kanns nicht recht nachvollziehen, weil ich wüsste jetzt nix, was typDataset nicht ebenso oder besser/einfacher könnte.
    Bei EF muss man aber deutlich mehr Code-Brimborium drumherum-coden.

    Ein grosser Vorteil von Dataset ist, dass man ganz ohne Datenbank damit arbeiten kann, und lauffähige Beispiel-Projekte zippen und veröffentlichen. EF-Tuts mit downloadbare Beispiele gibts auch, aber selten.
    Meine Rückmeldung nach weiteren 5h Sammeln von Basisinformationen:
    Wenn mit typisierten Datasets arbeiten, dann nur mit den DBExtensions. Sonst gibt es ein zu grosses Gebilde.
    Wenn ich das recht verstehe, wird dies von Microsoft aber nicht mehr sooo stark weiterentwickelt. Das kenne ich unterdessen und habe bereits einige Dinge gemacht (aber noch ohne DBExtensions).

    Mit dem Entity Framework würde ich mich von Vorteil in C# einarbeiten, da ich keine Beispiele "Entity Frameword & VB.NET" gefunden habe. Benutzer von EF bevorzugen C#, also sollte ich das auch tun.
    Das würde bedeuten, dass ich wieder einige (viele) Stunden Basiswissen schaufeln muss, um etwas zu generieren, mit dem auch ein Nachfolger leben kann. Und meine User müssen nochmal länger warten.

    Jetzt suche ich mir eine Münze, um zu entscheiden, wie ich weiterfahren soll.... hoffentlich bleibt sie nicht auf dem Rand stehen.

    Danke für eure Hilfe.





    Also, das Wochenende ist gebucht.
    @ErfinderDesRades
    Jetzt habe ich noch gefunden, wie ich die Extensions zum Laufen bringe.
    Wir hatten damals einfach mal einen Kurs "EF & VB.Net" gebucht.
    Da bekommt man das ordentlich präsentiert und kommt aus dem Staunen nicht mehr raus,
    wie simpel und idiotensicher man damit DB-Inhalte ansprechen kann.
    Aber stimmt schon, gerade für "EF & VB.Net" gibt es wenig Doku und Literatur.
    Da muss man bei C# reinschauen und das Zeug auf VB übertragen.
    An manchen Tagen gibt es zu allem Überfluss auch noch Ärger!