Gerade hatte ich es ansatzweise geschafft, nach jahrelangem Access-VBA plus SQL-Server mich mit dem .NET Framework 1.1 und dem ADO.NET DataSets zurechtzufinden. Und habe eine Windows-Anwendung mit einer halbwegs ordentlichen DAL-Schicht erstellt.

Und jetzt mit den VS-Versionen die ganzen Microsoft-Veranstaltungen zum Thema “kein Code mehr notwendig… Geht jetzt alles viel einfacher usw.”, bin ich vor allem ziemlich ratlos. Und stelle bereits mehrfach fest, daß es zwar recht schnell geht, damit einen Prototyp zusammenzuklicken, aber total umständlich ist, daran später etwas zu ändern.

In Grundlagen-Schulungen für Anfänger will ich nicht gehen, das ist zu wenig und zu langsam. Aber wie, wo und bei wem lernt man schnell und effizient, eine gute .NET 3.x Architektur in die Praxis umzusetzen?

*Stirn runzel* Liz

–> Genau das ist das größte Problem.
Ich bin Neuling auf den Gebieten .NET & OOP (Erfahrung bis jetzt: 6 Jahre Access & SQL Server)
Bisher beschränkt sich meine praktische Erfahrung mit .NET im wesentlichen auf alles was Karsten in seinem Post beschrieben hat (also bis zu der Stelle wo er anfängt zu erklären wie man es richtig machen sollte

Ich würde ja gerne mehr lernen, aber es ist verdammt schwer, Informationen zu finden mit denen ich was anfangen kann.

Alles was man so findet fällt normalerweise in eine der folgenden Kategorien (absteigend nach Fundhäufigkeit sortiert):

- Klicki-Bunti-Anleitungen (“Ziehen Sie die Tabelle einfach aufs Formular, und da ist sie schon – Ihre erste eigene Webseite!”)

- sehr theoretische Grundlagen von OOP (“Hund.Farbe=braun” / “Hund.Bellen()” / Vererbung Hund –> Dackel) die aber meistens genau an der Stelle aufhören wo die Verbindung zur Praxis anfangen würde

- OOP-Beispiele bei denen tatsächlich etwas aus einer Datenbank gelesen / in eine Datenbank geschrieben wird. Allerdings sind das dann Tabellen mit 3 Spalten und 3 Zeilen und meistens ohne Beziehung zu anderen Tabellen. Und Vererbung und alles was über Klasse.Property hinausgeht fehlt in diesen Beispielen auch immer, es wird NUR gelesen/geschrieben und sonst nix.

- Beispiele zur Schichtentrennung, meistens mit schönen Diagrammen auf denen man schön die Verbindungen PL –> BLL –> DAL etc. erkennt, aber ohne eine einzige Zeile Code

- Blogs wie dieser (oder auch die der meisten Leute die hier schon vor mir Kommentare hinterlassen haben) die ich regelmäßig in der Hoffnung lese noch etwas dabei zu lernen. Leider gehöre ich offensichtlich nicht zur richtigen Zielgruppe: Beiträge zu einem konkreten Problem (meistens mit viel Beispielcode) sind normalerweise ein paar Ebenen zu hoch für mich und behandeln Themen die für mich irgendwann mal relevant sein könnten wenn ich nur mal die Grundlagen kapieren würde (z.B.: wozu brauche ich heute Unit Tests, wenn ich keine vernünftige Klasse geschrieben kriege die ich damit testen könnte?). Beiträge in “Aufsatzform” (so wie dieser hier von Karsten) sind noch mit die informativsten Quellen wenn man die Theorie dahinter erstmal verstehen will, aber eben leider wieder nur Theorie.

Und da sitze ich nun mit meiner 45 GB großen SQL Server-Datenbank mit 370 Tabellen, meinem 95 MB großen Access-Frontend und weiß nicht wo ich anfangen soll:

Z.B. Klassendesign:
Im Moment benutze ich nirgendwo Klassen, sondern wenn ich in 20 Formularen Daten zu Aufträgen brauche, greife ich auch 20x auf die Auftragstabellen zu. Besser wäre es natürlich dafür eine Klasse zu bauen und die überall zu benutzen.
Die Klassen in den Beispielen (wie gesagt – Tabellen mit 3 Zeilen und 3 Spalten) sind auch immer schön einfach. Ich habe da aber z.B.:
- Aufträge
- jeder Auftrag gehört zu einem Kunden (separate Tabelle)
- jeder Auftrag hat n Positionen (separate Tabelle)
- jede Position hat n Produktmerkmale (separate Tabelle mit einem DS pro Produktmerkmal, n > 200!!)

Also müssen die Klassen irgendwelche Relationen untereinander haben um z.B. zusammen mit dem Auftrag die Positionen und einige ausgewählte Produktmerkmale zu laden.
Und dann muß ich sowas auch noch als Listen laden, z.B. als Liste aller offenen Aufträge mit diesen Daten.
In den Beispielen werden da dann Sachen gemacht wie:
-Auftragsliste laden, in Schleife durchlaufen
-für jeden Auftrag: Positionsliste laden, in Schleife durchlaufen
-für jede Position: nacheinander 3 Produktmerkmale laden (3 Abfragen)

Wenn man der einzige Benutzer in der Nordwind-Datenbank ist kann man das ja meinetwegen auch so machen, aber nicht bei einer 6stelligen Anzahl Aufträgen auf die >100 Benutzer zugreifen.
Solche Sachen mit Schleifen habe ich zu Anfang meiner Access-Zeit gemacht, bevor ich kapiert hatte wie Joins in SQL funktionieren. Und als ich die Schleifen durch Joins ersetzt hatte war die Anwendung auf einmal viel performanter.

Und da meine Liste eine Liste der offenen Aufträge zum Ausdrucken sein soll, ist auch nix mit Paging und erstmal nur 30 Datensätze laden – wenn es 1000 offene Aufträge gibt, dann müssen die auch alle gedruckt (und damit geladen) werden.

Beispiele zu sowas? Von wegen!

Oder Schichtentrennung:
Schichtentrennung hört sich in der Theorie nach einer tollen Sache an, aber wie setzt man sie um?
Wenn man dann doch mal ein paar Beispiele findet erfährt man je nachdem welchen Artikel man liest daß man den Datenzugriff mit Datasets / Typed Datasets / SQLDataSource / eigenen Objekten / Stored Procedures / … machen soll, und es werden auch gleich Begründungen mitgeliefert warum die verwendete Methode gut ist und alle anderen (also die, die die Autoren der anderen Artikel verwenden…) nicht.

Wenn man dann mal konkrete Beispiele dazu findet sind die meistens mit Datasets.
Die Daten werden dann geladen und gespeichert ohne daß man eine einzige Zeile SQL schreiben muß, das macht der Tableadapter alles von alleine.
Wenn man Sachen aus mehreren Tabellen haben will werden in den Beispielen einfach mehrere DataTables geladen und im Dataset gejoint (das ist ja soviel besser als eine SQL-Join-Abfrage, denn da kann man die Änderungen hinterher wieder automatisch speichern lassen ohne eine Zeile SQL zu schreiben!). Nur – meine Tabellen sind etwas größer als die in den Beispielen. Ich kann nicht einfach mal 2 Mio. Datensätze in den Speicher laden nur damit ein paar davon mit einer anderen Tabelle gejoint werden. Da denke ich jetzt: für sowas gibt es ja eigentlich Joins auf dem SQL-Server…

Und so geht es endlos weiter…

Ich frage mich immer ob ich der einzige bin der Probleme dieser Art hat.

Man findet immer nur entweder Beispiele für totale Anfänger die wirklich komplett bei Null anfangen, oder eben Beispiele für Superexperten (also von MVPs für MVPs) die davon ausgehen daß man diesen ganzen Architekturkram schon längst hinter sich gelassen hat und die sich deshalb nur mit einzeln herausgepickten Problemchen in viel höheren Sphären befassen.

Aber es muß doch noch mehr Leute geben die wie ich die Grundlagen beherrschen, schon genug Berufserfahrung etc. haben und für die nur der ganze .NET- und OOP-Kram neu ist?

Ne, im Ernst: Super geschrieben, genau ins Herz getroffen. Einzige Ausnahme: Das GridView Control kann man IMO problemlos verwenden, lediglich die DataSource Controls verschwinden hoffentlich bald wieder (wohl eher nicht, aber die Hoffnung … sterben … oder werden nicht mehr verwendet.

Es wird einfach viel zu viel zusammengeklickt. Mir grauts erst richtig, wenn die Leute selbst das SQL für die DataSource Controls zusammenklicken…

Nebenbei: Die ObjectDatasource benötigt IMHO nicht zwingend statische Methoden. Die entsprechende Klasse muss nur einen parameterlosen Kunstruktor haben.

Gruß
Jürgen

rptPersons.DataSource =
BusinessLayer.GetInstance().GetPersons();
DataBind();

SCNR *g*

Weg mit dem Krempel *g* (Um es mit deinen einfühlsamen Worten zu sagen^^)