vb.net Problem mit dem Programmaufbau eines Config-Tools

Mein Tip:
rede mit deinem Projektmanager, wie er sich das vorstellt und entwickle 
mit ihm gemeinsam ein Konzept!

So ein Konfigurationstool steht ja nicht im luftleeren Raum, sondern 
wird von jemanden benutzt. Und mit dem musst du reden!

Der für dich zuständige wird dir ein paar Brocken hingeworfen haben, 
damit du dir erst mal Gedanken darüber machst. Das schlimmste was du 
jetzt tun kannst, ist es, aus Scham dir eine Blösse zu geben, nicht mit 
ihm zu reden und ihn mit Fragen zu löchern. Wenn du das im stillen 
Kämmerlein machst (und hoffst hier mit dem Forum eine vernünftige Lösung 
hinzukriegen) dann prophezeihe ich dir jetzt schon eine Version 2.0, die 
praktisch wieder bei 0 anfängt.

Mein Ansatz wäre

Es gibt ein Gerät. Das ist erst mal eine Klasse für sich (ob Vererbung 
da Sinn macht, kann ich nicht entscheiden).

In deiner Datenbasis gibt es eine Reihe derartiger Geräte. (Liste, 
Array, wie auch immer)

Jedes Gerät hat eine Beschreibung. Da ist sein Name, Typbezeichnung, und 
ein Kommentarfeld für sonstige textuelle Information ist auch immer gut.

Jedes Gerät unterstützt aber auch eine Reihe von Aktionen.

So eine Aktion hat ihrerseits einen Namen (damit man später in der GUI 
einen Text zum Anzeigen hat), ist von einem bestimmten Typ und verfügt 
ebenfalls über ein Kommentarfeld (den man zb für Hilfetexte benutzen 
kann)

Welche konkreten Aktionen gibt es
* einfach ein Kommando zum Gerät schicken, ohne dass der Benutzer
  weiteres einstellen muss (vulgo: ein "Befehl")
* Benutzer kann aus mehreren möglichen Möglichkeiten auswählen
  und seine Auswahl wird an das Gerät übertragen (vulgo: eine "Option")

------
Soweit so gut.
Damit ergibt sich für mich (in angelehnter C++ Notation, VB müsste ich 
mich erst wieder einlesen) eine erste Klassenstruktur

1

class Action

2

{

3

4

   string Name;

5

   string Comment;

6

};

7

8

class OperationAction : public Action

9

{

10

11

   string Command;   // Text der für diese Aktion zum Gerät zu schicken ist

12

};

13

14

class Option

15

{

16

   string Name;      // wie heißt diese Option (kriegt der Benutzer zu sehen)

17

   string Command;   // Text, der für diese Option zum Gerät zu schicken ist

18

};

19

20

class OptionAction : public Action

21

{

22

   string Name;

23

   string CommandPreamble;  // Einleitungstext

24

   list<Option> Options;

25

   string Comment;

26

};

27

28

class Device

29

{

30

  string Name;

31

  string Comment;

32

  list<Action> Actions;

33

};

34

35

class Database

36

{

37

  list<Device> Devices;

38

}

Das Programm ist 2-geteilt.
Zum einen braucht es einen Teil, mit dem es möglich ist Geräte anzulegen 
und die Beschreibungen zu verändern. Das könnte zb eine klassische 
Oberfläche sein, in der die Dinge in List Controls aufgeführt sind, mit 
Editormöglichkeiten.

Zum anderen benötigt man eine Ausführungseinheit (kann auch ein eigenes 
Programm sein), welches sich die Beschreibung eines bestimmten Gerätes 
holt und daraus dann die Oberfläche generiert. OperationAction Objekte 
werden in Form von Buttons abgebildet (die dynamisch erzeugt werden), 
OptionAction Objekte werden in Form von Combo Boxen abgebildet (die 
natürlich ebenfalls dynamisch erzeugt werden).

Wie jetzt die jeweiligen Bedienelemente im Formular angeordnet werden, 
darüber müsste man reden. Es spricht ja nichts dagegen, dass man bei den 
jeweiligen Action Objekten auch noch zb Positionsangaben mitspeichert 
und es zb einen graphischen Editor gibt (als Teil des ersten 
Programmteiles) mit dem derjenige, der die Beschreibung erstellt, die 
Elemente anordnet. Vielleicht gibt es auch noch 'Action' die nicht ans 
Gerät geschickt werden, und die reine GUI Elemente darstellen, wie zb 
Fixtexte oder Bilder und nur dazu dienen, die Oberfläche besser zu 
gestalten.


Aber um Himmels Willen: rede mit deinem Projektleiter!

tantal.lpt schrieb:

> Ich könnte es auch als "quick and dirty" -Lösung realisieren

Da eure Geräte anscheinend konfiguriert werden, indem man ihnen 
Kommandos in Textform schickt, wäre eine Quick&Dirty Lösung, einfach die 
Konfiguration in Textform in eine Datei zu schreiben und auf Anforderung 
holt sich ein Tool diese Datei und überträgt den kompletten Dateiinhalt 
an das Gerät.
Für jeden Gerätetyp gibt es ein Subverzeichnis, in dem sich die Sammlung 
der Dateien befindet.

Was dann auch immer in diesen Dateien drinnen steht.
Das kann eine komplette Konfiguration sein, dass kann aber auch eine 
Konfiguration in Bezug auf einen Teilaspekt sein.

Das Tool bietet mir dann einfach eine Liste der relevanten Dateien an 
(mit einem Erklärungstext, der vielleicht ebenfalls in der Datei steht) 
und auf Knopfdrück jagt es den Dateiinhalt (ohne den Erklärungstext) an 
das Gerät raus.

Wenn du deine Datenbasis zb mit XML aufbaust, dann wäre der erste 
Programmteil zb etwas, wofür man nicht gleich ein eigenes Programm 
benötigt. Ändert sich die Datenbasis nicht allzuoft, dann kann man XML 
durchaus auch ganz einfach mit einem Texteditor bearbeiten. Es gibt aber 
auch Editoren, die mit einer zusätzlichen Beschreibung XML Files 
editieren können, ohne das der Bediener etwas von XML verstehen muss
(zb 
http://www.altova.com/de/produkte/authentic/xml_db_formular_editor.html

Damit wäre der erste Teil schon mal ganz gut abgedeckt und du musst dich 
nur um den 2.ten Teil kümmern, der aus der XML Beschreibung dann die 
Oberfläche zur Laufzeit erzeugt mit der dann dein Benutzer tatsächlich 
arbeitet.
Wobei XML hier wiederrum den Vorteil hat, dass VB komplette Klassen 
dafür mitbringt. D.h. du musst überhaupt keine Klassenstruktur erfinden, 
sondern lässt dir von den vorhandenen XML Klassen die Beschreibung 
einlesen (DOM-Modell) und arbeitest dann direkt damit.

In eine ähnliche Kerbe schlagen Lösungen, die zb auf einer Datenbank 
aufsetzen. Auch da stellt dir der Datenbankhersteller Werkzeuge zur 
Verfügung, mit der du einfach Formulare zur Pflege der Datenbank 
erstellen kannst. Der Zugriff auf die Datenbank ist dafür etwas 
komplizierter, dafür kannst du aber eine Datenbank wieder einfacher 
zentral pflegen.

Auch die DLL Lösung von weiter oben ist nicht von der Hand zu weisen, 
hat aber den Nachteil, dass man bei Erweiterungen oder Änderungen immer 
einen Programmierer braucht, während die anderen Lösungen komplett 
datengetrieben sind. Im Prinzip könnte jede Sekretärin ein neues Gerät 
damit anlegen.

Möglichkeiten gibt es viele. Aber mit jeder Entscheidung, die du jetzt 
triffst, musst du jahrelang leben. Daher sollte diese Entscheidung 
besser eine gute sein! Und da du noch nicht über die Erfahrung verfügst 
abzuschätzen, welche Auswirkungen eine Entscheidung auch in Zukunft mal 
haben wird/kann, musst du mit jemandem reden, der das kann und der auch 
in der Lage ist die weitere Entwicklung (sowohl technologisch als auch 
strategisch) innerhalb eurer Firma abzuschätzen (zb auch was mit diesen 
Konfigurationsdaten noch alles gemacht werden könnte). Das kann ich von 
hier aus nicht, ich kann dir nur Möglichkeiten aufzeigen.