(C#) Ideen für Klassenaufbau gesucht

[Matthias S. (da_user)]

Hi,

ich bin derzeit ein bisschen drüber mir etwas Datenbankmässiges zu 
basteln, um einen Überblick über Anlagen und der darin verbauten 
(Ersatz-)Teile und Reparaturen zu erhalten.

Ich habe mir jetzt gedacht ich nehme eine Basisklasse "Bauteil", das hat 
Felder wie "Name", "Typ", "ID", eine Liste "Historie" (gekauft am, 
eingebaut am, ausgebaut am, repariert am,...)
Daraus leite ich dann verschiedene Bauteile ab, z.B. die Klasse "Motor".
Oder die Klasse "Anlage", die z.B. ein Feld für die Klasse "Motor" 
bekommt.

Und dann könnte ich noch die Klasse "Gebäude" ableiten, mit einer 
"Anlagenliste" die Klassen vom Typ "Anlage" enthält.

Als GUI stelle ich mir auf der einen Seite eine TreeView vor, auf der 
anderen dann einige Steuerelemente die zum ausgewählten Element dann 
Daten anzeigen. Diese Daten sind ja glücklicherweise alle ziemlich 
gleich, was meinen Gedanken zu gute kommt, die GUI möglichst einfach und 
flexibel zu gestalten.

Sprich: Wenn ich irgendwann z.B. die FUs mit aufnehmen möchte, erstelle 
ich eine Klasse "FU", die Klasse Anlage erhält ein Feld dafür und die 
GUI sucht sich das selbst raus. Und letzteres wird schwer, weil dann 
alle Klassen doch wieder irgendwie gleich sein müssten. Dann bekomme ich 
aber die Beziehungen untereinander nicht mehr aufgebaut.

In meinem Hinterstübchen rührt sich etwas, dass sich Schnittstelle 
genannt hat. Wenn ich das jetzt richtig interpretiere könnte ich eine 
Schnittstelle bereitstellen, die in jede Klasse implementiert wird und 
über die ich dann für die GUI standardisiert die für sie notwendigen 
Daten bereitstelle? Z.B. fasse ich dort die Felder "Motor" und "FU" in 
der Klasse "Anlage" zu einem Array "verbaute Teile" zusammen.

Ist jetzt doch etwas mehr Text geworden als gedacht... ;-)

Bevor ich mich total in was verrenne, was dann letzten Endes nicht 
funktioniert - was meint Ihr: Wäre eine Schnittstelle ein gangbarer Weg? 
Oder evtl. ganz andere Vorschläge (sofern diese nicht lauten: "nimm was 
gscheides" od. ähnl.)?

VG
da_user

[Oliver S. (oliverso)]

Na ja, der Gedanke, an Stelle des selbsgefrickelten Bastelcodes einfach 
eine der unzähligen fertigen Datenbanken zu nehmen, könnte einem schon 
kommen.

Professionell baut man sowas mit Excel ;)

Oliver

[Matthias S. (da_user)]

Oliver S. schrieb:
> Na ja, der Gedanke, an Stelle des selbsgefrickelten Bastelcodes einfach
> eine der unzähligen fertigen Datenbanken zu nehmen, könnte einem schon
> kommen.

Klar.. schon öfter gesucht & auch gefragt, nix gefunden.

Oliver S. schrieb:
> Professionell baut man sowas mit Excel ;)

Wenn dann Access ;-)
Haben wir aber leider nicht :-(

[MaWin (Gast)]

Matthias S. schrieb:
> Daraus leite ich dann verschiedene Bauteile ab

Der übliche Unsinn aus dem aufgeblähte, nie mehr wartbare Programme 
entstehen.

Die Klassen einer Datenbank heissen Connection, Row/Table und 
Field/Datatype (und fancy Zeug wie hierarchische Transaktionen oder 
scrollbare Windows). Und es ist scheissegal, welche Daten darin 
gespeichert werden.

Man baut Interfaces generic auf, die müssen sich von selbst anpassen 
können. Eine gut designte Datenbank kann die dahinterstehende 
Implementation (dBase, ODBC, neuronNetz) genau so transparent ändern, 
wie einer Tabelle nach einspielen von 1000 Datensätzen einfach noch 2 
Felder hinzugefügt werden können, es müssen nicht indizierbare Felder 
nichtmal Datenbankfelder sein sondern die können variabel in einem Blob 
stecken. Nur wenn man mal über sie indiziert, müssen sie ausgepackt 
werden.

Man bildet mit OO nicht die (angebliche, aber meist zu kurz gedachte) 
Realität ab, denn die Realität ist unlogisch und widersprechend, sondern 
die Struktur der Programminternas, wenn man überleben will.

[Mark B. (markbrandis)]

Matthias S. schrieb:
> Hi,
>
> ich bin derzeit ein bisschen drüber mir etwas Datenbankmässiges zu
> basteln, um einen Überblick über Anlagen und der darin verbauten
> (Ersatz-)Teile und Reparaturen zu erhalten.

Du willst also Informationen verwalten. So weit so gut. Was spricht 
dagegen, diese Informationen in eine Datei einzutragen? Und die Datei 
dann in einem Versionierungssystem abzulegen? Ob das dann Word oder 
Excel oder XML oder CSV oder sonstwas ist, ist erstmal beliebig.

[Wolfgang Höhne (Gast)]

https://www.blogofpi.com/crud-using-blazor-and-entity-framework-core/#:~:text=%20CRUD%20using%20Blazor%20and%20Entity%20Framework%20Core,create%20a%20page%20to%20list%20the...%20More%20

[Matthias S. (da_user)]

Mark B. schrieb:
> Du willst also Informationen verwalten. So weit so gut. Was spricht
> dagegen, diese Informationen in eine Datei einzutragen? Und die Datei
> dann in einem Versionierungssystem abzulegen? Ob das dann Word oder
> Excel oder XML oder CSV oder sonstwas ist, ist erstmal beliebig.

Im Moment läuft das ganze in der Tat über Word. Das ist ineffektiv, 
unübersichtlich & schlecht pflegbar.

Der Tipp mit der Datenbank ist natürlich nett gemeint, ist aber nicht 
das was ich suche. Den wie Mark B. schon andeutet: wie man die Daten 
speichert - XML, CSV, Datenbank, binär - "ist erstmal beliebig".
Und wenn ich eine Datenbank nehmen würde, würde ich wohl über das 
Entity-Framework arbeiten und zwar nach "Code-First". Sprich: ich müsste 
auch erstmal die Daten innerhalb meines Codes organisieren.