Hallo liebe VB Paradise Gemeinde.
Ich habe ein paar Fragen bezüglich eines neuen Projekts. Undzwar soll man damit verwaltet werden:
1. Bestellungen von Artikeln (pro Kunde)
2. den Lagerbestand von "Zukaufteilen" (pro Artikel)
3. bereits ausgelieferte Artikel (dort sollen dann auch die Monteure angegeben werden)

Die Datenbankstruktur ist für mich nicht das Problem, sondern eher womit man das ganze realisiert. Ich habe bereits viel über Programm-Architektur gelesen, aber je mehr ich lese, umso weniger verstehe ich. Erst hatte ich vor das alles über typisierte Datasets zu machen, aber ich habe nicht verstanden, wie man soetwas vernünftig in ein 3-Schichten Model unterbringt.
Desweiteren habe ich Sachen über MVP, MVC und MVVM (wobei letzteres ja eigentlich eher für WPF gedacht ist) gelesen. Das Prinzip ist mir klar, aber ich weiß nicht, ob das das richtige für mich ist.
Ist es überhaupt sinnvoll das Alles mit typisierten Datasets zu machen, oder wäre es bessser mit Entity Framework zu arbeiten? Oder vielleicht sogar nur mit direkten SQL Abfragen?
Wie würdet ihr soetwas angehen?
Fragen über Fragen

also entweder typisiertes Dataset oder EF.

kein untypisiertes Gewurstel mit selbstgebastelten Abfragen.

Bezüglich der Architektur mach dich nicht verrückt.
Das imo einzig wichtige ist, dass die Daten nur an einer Stelle im Programm gehalten werden.

Achso, was noch wichtig ist: Verwende Databinding.

Die Pattern MVP und MVC funktionieren garnet. Man kann nicht den Controller vom View trennen, denn das View besteht aus Controls, und da ist halt Controlling fest drin eingebaut, deswegen heißen die Dinger ja auch "Control".

Und auch MVVM benutze ich zumindest ganz ungeniert auch in abgespeckter Version.
Das heisst, ich trenne strikt View und Model, aber wenn es keinen Bedarf gibt für besondere ViewModel-Funktionalität, dann konstruiere ich auch keine Viewmodels, die dann ja nix zu tun hätten, ausser Bugs zu haben, sondern binde fröhlich direkt an die Model-Klassen.

blackdahila schrieb:

Wie würdet ihr soetwas angehen?

ich würde WinForms und good old typDataset nehmen, es sei denn, es ist ganz dolle User-Experience gefragt.
Weil mit typDataset kann man die Anwendung fast fertig ausprogrammieren, und die DB erst im Nachhinein hinterlegen.
Das ganze Programm: Datenverarbeitungs-Vorraussetzungen
Beachte, dass im verlinkten Post weiter-verlinkt ist, und dort weiter-weiter und so weiter.

Für Wpf besteht die typDataset-Option nicht, sondern da biste auf EF festgelegt, und immer mit einer DB am rumfuhrwerken.
Kleines Sample: EntityFramework-CodeFirst-Sample

Hallo ErfinderDesRades. Erstmal danke für deine schnelle Antwort.
Dann lag ich mit meiner ersten "Idee" ja gar nicht mal so falsch. Wenn dich richtig verstanden habe, dann würde es also erstmal reichen ein Projekt für das UI und eins für das Dataset zu erstellen und bei Bedarf entweder extra Klassen für "Business-Logik" oder halt noch ein extra Projekt!? Deine Videos hatte ich mit auch schon angeschaut und finde sie sehr hilfreich. Da sieht man mal, wie viel man mit wenig Code erreichen kann.
Aber was ist, wenn man z.B. ein Datatable mit "Zukaufteilen" hat und ein Datatable mit "Artikeln" welche in m:n Relation stehen über den Datatable "ArtikelZukaufteil", wo dann auch die jeweilige Anzahl der Zukaufteile pro Artikel angegeben ist? Ich würde das dann über eine Linq Join Abfrage machen, wenn man die "Zukaufteile" mit der entsprechenden Anzahl in einem DataGridView haben möchte. Daraus bekommt man dann zwar einen Anonymen Typen, wenn man mit .toList() arbeitet, Aber zum anzeigen im DGV reicht das ja. Danach kann mit den "IDs" der selektierten Zeile weiterarbeiten um an die Daten zu kommen. Oder gibt es da einen eleganteren Weg?
Ich hoffe ich habe das einigermaßen verständlich beschrieben

blackdahila schrieb:

Oder gibt es da einen eleganteren Weg?

ja, und das ist in 4-View-Videos ja auch gezeigt: Der m:n - View.

LInq-Join oder Sql-Join kannste ziemlich vergessen, denn solche Ansichten kann man nicht geändert zurückspeichern.

Das Video habe ich mir angeguckt, aber das ist nicht genau das was ich brauche, da ich ich alles in einem Datagridview angezeigt haben möchte (die zukaufteile pro Artikel, sowie deren benötigte Anzahl, welche in dem Datatable "ArtikelZukaufteil" angegeben ist).
Es würde mir auch reichen, dass man das Datagridview nur zum anzeigen nutzt, da man mit der Join Abfrage als Datasource eh keine Änderungen vornehmen kann. Ich würde das dann in einer zweiten Form über Textboxen machen.
Jetzt stellt sich mir nur die Frage, ob ich die Einträge mit einer extra Class über Properties in die Textboxen lade und dort dann überprüfe, oder direkt über Databindings und dann mit begin- und endedit arbeite.

-edit-
Ich habe das Thema aus Versehen mit VB.net gekennzeichnet, obwohl es sich um C# handelt, aber da es sich hier um allgemeine Fragen handelt, sollte das nichts zur Sache tun

blackdahila schrieb:

da ich ich alles in einem Datagridview angezeigt haben möchte (die zukaufteile pro Artikel, sowie deren benötigte Anzahl, welche in dem Datatable "ArtikelZukaufteil" angegeben ist).

Aber das ist doch genau, was in dem Video behandelt wird!
Stell dir vor, was dort "Kategorie" heisst, hiesse "Artikel", und was derzeit "Lieferant" heisst, hiesse "ZukaufTeil".
Und stell dir vor, was derzeit "Artikel" heisst, hiesse "ArtikelZukaufl". Und statt des Preises wäre eine Anzahl eingerichtet.
Dann könntest du im rechten Grid alle Zukaufteile eines Artikels angugge, zufügen, löschen, ihre Anzahl festlegen - was wolle.

Also die Videos wollen dir nicht eine konkrete Lösung deines Problems geben, sondern die Struktur musste verstehen, und die ist zwischen Artikel, Zukaufteil, ArtikelZukauf (bei dir) und Kategorie, Lieferant, Artikel (bei mir) dieselbe: es ist eine m:n - Relation.
Und dem User wirds als m:n - View präsentiert.