Der richtige Weg, um Daten zu separieren

[SeToY]

- Ich hoffe, das ist die richtige Kategorie -

Hallo zusammen,

ich habe momentan in meinem C#-Code einen Enum, welchen wir, der Einfachheit halber, einfach Typen nennen.

Innerhalb dieses Enums gibt es dann natürlich "Typ1", "Typ2", "Typ3", ... und wiederrum im Code eine ComboBox "comboBoxTypen" mit "1", "2", "3", ...

Nun ist es auf Grund der Erweiterbarkeit und Sortierbarkeit natürlich eine (sehr!) schlechte Idee, diesen im Code folgendermaßen zu verwenden:

MyObject obj = new MyObject();

obj.Typ = comboBoxTypen.SelectedIndex

Sobald ich die Sortierung ändere, einen "Typ1.1" hinzufüge oder sonst irgendwas Wartungs-Technisch mit dem Dingen anstelle, fliegt mir natürlich die halbe Datengrundlage (MSSQL Table) weg.

Wie ist da euer weg, um es möglichst dynamisch im Code zu halten?

Erstellt ihr eine Klasse "Typ" mit Properties "ID" und "Beschreibung" und bindet dann eine vorher erstellte Collection (z.B. IEnumerable<Typ>) an die ComboBox?

Oder vielleicht etwas anderes? Bin gespannt.

Vielen Dank.

SeToY

[MartinSt]

Ich würde es erstmal weniger aus Sicht der Klassen und der Datenbank sehen, als vielmehr aus Sicht der zugrundeliegenden BOs, die ja irgendwelche realen Dinge repräsentieren.

Wie hoch ist dann die Wahrscheinlichkeit, dass sich die genannten Typen ändern?

Und inwieweit ist mit einer Änderung dann sowieso eine Überarbeitung der Software nötig, z.B. weil sich damit die rechtliche Situation völlig ändert?

Wenn die Wahrscheinlichkeit hoch ist, würde ich die BOs und Typen per XML o.ä. definieren und daraus dann die Klassen und Datenbankstruktur generieren.

Gruß Martin

[Pixie]

Warum muss es denn der selectedIndex sein? das ist doch C#? Da haben Comboxen doch einen DisplayMmber und einen ValueMember und vor allem einen SelectedValue. Der SelectedValue liefert den ValueMember des ausgewählten Items und der ist idealerweie die eindeutige ID des in der collection zur Verfügung gestellten Typs. Der Displaymember kann auch eine berechnete und nicht in der Db angebildete Eigenschaft sein.

[SeToY]

Die Wahrscheinlichkeit ist nicht hoch, es könnte aber passieren. Ich rede ungefähr von einer Wahrscheinlichkeit um die 30% - das reicht imho aber aus, um sich darum Gedanken zu machen.

Mein Problem ist z.B., dass Enum-Value '0' den Wert 'Keine Angabe' repräsentiert. Den benötige ich aber nicht in jeder (in diesem Falle) ComboBox.

Ergo habe ich SelectedIndex = 0 = Keine Angabe in einer ComboBox, wo "Keine Angabe" angezeigt werden soll. In einer anderen ComboBox soll aber nicht "Keine Angabe" angezeigt werden, somit wäre der SelectedIndex = 0 = Typ1

Ich habe mir jetzt überlegt, ein Model zu bauen (Id, Index, DisplayName) und zur Compile-Time eine List<T> mit den gefüllten Daten zu erstellen.

Somit hätte ich dann DisplayMember = DisplayName, ValueMember = Id und somit SelectedValue = List<T>[item].Id...

Oder gäbe es da eine bessere Vorgehensweise?

[SilentDemise]

ja...ein ViewModel an die GUI binden. Streng genommen beschreibst du auch 2 verschiedene Problemdomänen und solltest daher auch verschiedene Enums dafür deklarieren. SoC und so.

[Gast runtimeterror]

Ich bin mir auch nach dem zehnten Mal lesen nicht sicher, was du genau benötigst. Ich verstehe deine Anfrage so, dass du unabhängig von der automatischen Indexierung von Enums eine eigene Nummer vergeben willst, die z.B. der Persistierung in der Datenbank dienen soll.

Das hier ist mein Standardkonstrukt in Java um das zu erreichen (die Übersetzung in C# dürfte nicht allzu schwer sein - die Sprachen sind sich sehr ähnlich).

public enum Typen {


	TYP1(1, "Typ 1"), TYP2(2, "Typ 2");


	public final int index;

	public final String name;


	private static final Map<Integer, Typen> indexMap = new HashMap<>();


	static {

		for (Typen typ : Typen.values()) {

			indexMap.put(typ.index, typ);

		}

	}


	private Typen(int index, String name) {

		this.index = index;

		this.name = name;

	}


	public static Typen getByIndex(int index) {

		return indexMap.get(index);

	}


}


// Beispiele

Typen zahlZuEnum = Typen.getByIndex(2);

int enumZuZahl = Typen.TYP1.index;

[/PHP]

Mal davon abgesehen, dass alle populären Datenbanken Enums unterstützen und sich darüber freuen, wenn man von dieser Funktion Gebrauch macht. Die Notwendigkeit Enums in Zahlen umzuwandeln und umgekehrt ergibt sich meist nur noch bei der Implementierung bestehender Binärformate.

[SeToY]

Hallo,

genau. Eine eigene Zählweise anstatt die von Enums. MS SQL unterstützt zwar Enums, das Entity Framework aber erst mit .NET 4.5.

Ich danke euch für eure Antworten. Hat mir weitergeholfen

Sent from my HTC Sensation XE with Beats Audio Z715e