Verwaltung Kundenspezifische Einstellungen

[eskimo328]

In unserer Firma haben wir eine Java-Swing Anwendung (mobiles Außendienstsystem zur Auftragserfassung), die mittlerweile von mehrere Kunden genutzt wird. Jedes Kunde hat sonderwünsche.
So müssen an diversen Stellen in der Anwendung zwischen Kunden unterschieden werden, welcher Kunde was darf oder welche Einstellung hat.

Bisher wird das folgendermaßen gelöst:
In der Klasse KundenSettings wird definiert welcher Kunde was darf und an der entsprechenden Stelle wird dann abgefragt ...

if(KundenSettings.EINSTELLUNG1())
    // doSomething ...

public class KundenSettings
{
	private static KundenSettings INSTANCE = new KundenSettings();
	
	/**
	 * Beschreibung EINSTELLUNG1;
	 */
	private boolean EINSTELLUNG1;

	/**
	 * Beschreibung EINSTELLUNG2;
	 */
	private boolean EINSTELLUNG2;

	// ...
	
	private KundenSettings()
	{
		// kundenabhaengige settings
		switch (GeneralInfo.getKunde())
		{
			case KUNDE_A
				this.EINSTELLUNG1 = true;
				this.EINSTELLUNG2; = true;
				break;
			
			case KUNDE_B
				this.EINSTELLUNG1 = false
				this.EINSTELLUNG2; = true;
				break;
		}
	}
	
	public static boolean EINSTELLUNG1()
	{
		return KundenSettings.INSTANCE.EINSTELLUNG1;
	}
	
	public static boolean EINSTELLUNG2()
	{
		return KundenSettings.INSTANCE.EINSTELLUNG2;
	}
}

Jedoch wächst die Klasse KundenSettings mit jedem neuen Kunden und vorallem mit jeder neuen Einstellung. Mittlerweile umfasst sie 1500 Zeilen und ist recht unübersichtlich.

Habt ihr eine Idee wie man solche Einstellung noch verwalten kann? Bitte genauere Beschreibung und keine Aussagen wie: "wie wäre es mit XML?".

 

[SlaterB]

statt XML geht auch TXT, aber direkter Java-Quelltext ist auch nicht schlimmer, falls die Datei nicht zur Laufzeit bearbeitet werden muss,

----

'wie wäre es mit' Datenbank?

-------

gibt es irgendwelche Gemeinsamkeiten bei den Einstellungen?
kannst du z.B. einen Default-Wert konfigurieren und nur bei 10% der Kunden etwas anderes explizit definieren?

--------

kannst du Kunden zusammenfassen a la
case KUNDE_A:
case KUNDE_B:
case KUNDE_C:
this.EINSTELLUNG1 = true;
break;
case KUNDE_D:
case KUNDE_E:
case KUNDE_F:
this.EINSTELLUNG1 = false
break;

oder noch kürzer Listen/ Arrays anlegen:
einStellung1 = {KUNDE_A, KUNDE_B, KUNDE_C, ..}


diese Zusammenfassungen entweder für alle Einstellungen oder nur bestimmte Merkmale

 

[eskimo328]

Die Einstellungen werden vom Entwickler einmalig gesetzt. Die werden dann beim Programmstart 1 Mal geladen.
Eine Datenbanklösung halte ich nicht für sinnvoll.
Bisher sind es ca. 100 solcher Einstellungen. Also 100 Attribute und 100 entsprechende statische Methoden, über welche man die Attribute abfragen kann. Zudemm hat jedes Attribut einen Kommentar, dass man auch weiß, welches Attribut was macht. Dami kommt man auf ca 1500 Zeilen Code.
Es wird nicht für jeden Kunden jede Einstelung konfiguriert. Nur die Einstellungen die abweichen. Somit sind bei jedem Kunden bisher ca. 20-40 Einstellungen zu setzen.

 

[Landei]

WTF?

Normalerweise macht man sowas mit einer properties-Datei (oder hier besser zweien: eine für den "Standard" und eine für den speziellen Kunden), und die Properties-Klasse nimmt dir schon viel Arbeit ab. Vom Umfang her sind 40 Zeilen auch nicht zuviel. Im Java-Code finde ich sowas grau! en! haft!

 

[eskimo328]

also angenommen ich habe eine settings-default.ini und eine settings-kundea.ini und eine settings-kundeb.ini

da steht denn zb drinnen:

EINSTELLUNG1=true
EINSTELLUNG2=false

wie mache ich es mit der beschreibung der einstellungen? bisher habe ich einen javadoc kommentar: /** ... */
ich möchte ja, dass jedes attribut irgendwie beschrieben wird, sodass man was für was jede einstellung überhaupt gut ist.

was haltet ihr von etwas in dieser richtung:

[XML]
<settings>
<setting>
<key>EINSTELLUNG1</key>
<value>false</value>
<description>Beschreibung der einstellung1 ...</description>
<value kunde="A">true</value>
<value kunde="C">true</value>
</setting>
<setting>
<key>EINSTELLUNG2</key>
<value>true</value>
<description>Beschreibung der einstellung2 ...</description>
<value kunde="A">false</value>
</setting>
</settings>
[/XML]

 

[Dragonfire]

Wie sieht es denn mit einem objektorientierten Lösung aus?

Man könnte doch einfach für jede Einstellung ein Objekt erzeugen,
jeder Kunde hält eine Referenz auf die Einstellungen die ihm gestattet sind
auszuführen.

Bei der if-Anweisung überprüft man dann einfach,
ob der aktuelle Kunde das Einstellungs-Objekt hat/referenziert.

Diese Lösung hätte den Vorteil,
dass man auch zur Laufzeiten die Rechte ändern kann.
Des weiteren könnte ein Einstellungsobjekt eine Liste alle Kunden haben
die gerade diese Objekt referenzieren (wobei ich mir nicht sicher bin,
ob das guter Programmierstil ist).

 

[SlaterB]

if (Einstellungen.isEinstellung1(kunde))

if (Einstellungen.Einstellung1.contains(kunde))

if (kunde.has(Einstellungen.Einstellung1))

das ist doch alles Jacke wie Hose

 

[tme]

Für mich sieht das wie ein Ruf nach einem Repository aus. Wir lieferten dafür eine (üblicherweise read-only verbundene) Datenbank mit den programmweit gesetzten, aber nichtsdesdotrotz pflegebedürftigen Einstellungen und Grundkonfigurationen aus. Dazu gehören z.B. auch GUI-Festlegungen, es lassen sich die Designs der GUI-Komponenten dort hinterlegen. Diese werden dann zur Runtime geladen und die Komponenten entsprechend der Repository-Einstellungen angezeigt.

Ein Repository kann eine oder mehrere wie auch immer formatierte Dateien, eine Datenbank oder jede andere strukturierte Hinterlegung von Daten sein.

Thomas

 

[eskimo328]

if (Einstellungen.isEinstellung1(kunde))

if (Einstellungen.Einstellung1.contains(kunde))

if (kunde.has(Einstellungen.Einstellung1))

das ist doch alles Jacke wie Hose

des is ja in etwa die lösung wie sie bisher schon verwendet wird!?!

 

[SlaterB]

war bezogen auf Dragonfire's Vorschläge wie 'Man könnte doch einfach für jede Einstellung ein Objekt erzeugen'

 

[Dragonfire]

Aber wär meine Lösung nicht ein wenig dynamischer und würde weniger Codeänderungen
zur Folge haben?
Man könnte einfach in der Klasse "KundenSetting" eine HashMap mit allen Einstellungsobjekten anlegen, in der man dann neue Einstellungen einfügt.

Man müsste dann dem jeweiligen Kunden immer nur die Objekte hinzufügen;
aus der Hash auslesen und übergeben.

Das einzige was anderes ist als zum bisherigen Entwurf,
dass man dann keiner getter Methoden mehr braucht,
sondern nur den String

Im Endeffekt habt ihr aber recht,
ist eigentlich nichts anderes ...

 

[Landei]

also angenommen ich habe eine settings-default.ini und eine settings-kundea.ini und eine settings-kundeb.ini

da steht denn zb drinnen:

EINSTELLUNG1=true
EINSTELLUNG2=false

wie mache ich es mit der beschreibung der einstellungen? bisher habe ich einen javadoc kommentar: /** ... */
ich möchte ja, dass jedes attribut irgendwie beschrieben wird, sodass man was für was jede einstellung überhaupt gut ist.

Hast du gelesen, was ich geschrieben habe? Jeder Kunde bekommt seine eigene Properties-Datei (und es gibt noch einen "Master" mit den default-Werten). Halte ich immer noch für die beste Variante.

 

[eskimo328]

wenn ich denn die variante mit der properties datei verwende, hat es vorteile die properties im xml format zu speichern? oder ist es grad egal?

 

[SlaterB]

XML ist genau dann gut, wenn es Sinn macht (z.B. komplexe Datenstrukturen mit vielen Regeln wie Anzahl Subelemente) oder wenn die Verarbeitung es zwingend erfordert,
in diesem einfache Falle kannst du auch das Properties-Txt-Format verwenden:
x=true
y=true
z=false

 

[eskimo328]

wenn man die Klasse java.utils.Properties und dem xml format nutzt, wird folgende dtd vorgegeben: http://java.sun.com/dtd/properties.dtd

[XML]
<!--
Copyright 2006 Sun Microsystems, Inc. All rights reserved.
-->

<!-- DTD for properties -->

<!ELEMENT properties ( comment?, entry* ) >

<!ATTLIST properties version CDATA #FIXED "1.0">

<!ELEMENT comment (#PCDATA) >

<!ELEMENT entry (#PCDATA) >

<!ATTLIST entry key CDATA #REQUIRED>

[/XML]

das ist ja nicht wirklich komplex. also lohnt es sich nicht wirklich xml zu nutzen. da ist das einfache txt-formaut fast noch übersichtlicher denke ich !?!

 

[Landei]

Würde ich auch sagen.

 

[eskimo328]

habe nun mal eine Variante umgesetzt. was haltet ihr davon? Habt ihr noch Verbesserungsvorschläge?

1. eine properties datei mit den default werten: kunde_default.properties

#  Kommentar Einstellung1
EINSTELLUNG1 = false

#  Kommentar Einstellung2
EINSTELLUNG2 = true

2. im gleichen Stil gibt es pro Kunde eine Properties Datei in dem nur noch die Keys mit den zugehörigen Werten stehen, die von den defaults abweichen.

3. dann gibt es eine enum Klasse in der die Keys stehen (ich verwende ungern String)

public enum KundenSettingKeys
{
	EINSTELLUNG1,
	EINSTELLUNG2,
	...;
}

4. Eine solche Property wird wie folgt abgefragt

if(KundenSettings.getProperty(KundenSettingKeys.EINSTELLUNG1))
...

5. Hier wird alles initialisiert und hier steckt die getProperty() MEthode:

public class KundenSettings
{
	private static KundenSettings instance = new KundenSettings();
	private Properties propertiesDefault;
	private Properties propertiesKunde;
	
	private KundenSettings()
	{
		/* load properties with default values */
		loadDefaultProps();
		
		/* load properties */
		loadKundenProps();
	}
	
	/**
	 * load default values from "manis_default.properties"
	 */
	private void loadDefaultProps()
	{
		propertiesDefault = new Properties();
		
		URL inDefault = KundenSettings.class.getResource("manis_default.properties");
		
		try
		{
			propertiesDefault.load(inDefault.openStream());
		}
		catch (IOException e)
		{
			LM_Logger.printStackTrace(e, this);
		}
	}
	
	/**
	 * load kundenspecific values 
	 */
	private void loadKundenProps()
	{
		propertiesKunde = new Properties(propertiesDefault);
		
		int kundenNr = // getKundenNr();
		
		URL inDefault = KundenSettings.class.getResource("kunde_"+String.valueOf(manisNr)+".properties");
		
		try
		{
			propertiesKunde.load(inDefault.openStream());
		}
		catch (IOException e)
		{
			LM_Logger.printStackTrace(e, this);
		}
	}
	
	/**
	 * @param key
	 * @return boolean
	 */
	public static boolean getProperty(ManisSettingKeys key)
	{
		String property = instance.propertiesKunde.getProperty(key.name());
		
		if(property == null || property.length() <= 0)
			return false;
			
		return new Boolean(property);
	}
}