Verschiedene Kundenversionen in einem Programm pflegen??!

[Polarwar]

Hallo zusammen,

ich habe da mal wieder eine Frage, habe auch versucht über die SuchFkt. erfolgreich zu sein, was aber nicht geklappt hat.

Ich habe da ein Projekt was bei verschiedenen Kunden eingesetzt wird. Viele kennen es vielleicht, der eine Kunde möchte noch dieses, der andere noch das.... Wie bekomme ich nun eine vernünftige Verwaltung hin, ohne mit 10 verschiedenen Kundenvarianten arbeiten zu müssen. Denn wenn nun bei einer grundlegenden Fkt. etwas geändert werden muß, muß ich immer in 10 Versionen die gleiche Änderung durchführen!

Mir schwebt da eine Lösung vor, in der ich ein Compilat habe bei dem ich auf einer Supervisorseite, die Einstellungen mache, wie es denn nun bei dem Kunden auszusehen hat und wie das Programm reagiert. Doch hier wird es auch schon wieder tricky und verdammt kompiliziert!??!

Wie macht ihr denn soetwas!??!

Gruß und schon mal Vielen Dank für die Hilfe..
Polarwar

[Phoenix]

hrm.. spontan würde mir einfallen, die Funktionen die pro Kunde unterschiedlich sind, in dll's auszulagern. Somit definierst Du einmalig die schnittstelle, ziehst die orginialimplementierung in eine allgemein DLL und lieferst dies an alle Kunden aus. Der spezial-Kunde mit der Änderung bekommt seine persönliche eigene DLL ausgeliefert.

Bei weiteren Änderungen muss Du dann nur an der dll für den einen Kunden arbeiten, eine grundlegende Änderung in dem Modul wird in die orginal-DLL eingepflegt und an alle Kunden mitverteilt.

[franktron]

Zitat von Phoenix:

hrm.. spontan würde mir einfallen, die Funktionen die pro Kunde unterschiedlich sind, in dll's auszulagern. Somit definierst Du einmalig die schnittstelle, ziehst die orginialimplementierung in eine allgemein DLL und lieferst dies an alle Kunden aus. Der spezial-Kunde mit der Änderung bekommt seine persönliche eigene DLL ausgeliefert.

Bei weiteren Änderungen muss Du dann nur an der dll für den einen Kunden arbeiten, eine grundlegende Änderung in dem Modul wird in die orginal-DLL eingepflegt und an alle Kunden mitverteilt.

Ganau so haben wir das auch.

[Polarwar]

Gedacht habe ich auch schon daran, nur konnte ich mich mit dem Gedanken nicht anfreunden.

Es geht nicht nur um funktionalität, auch der Aufbau der Form kann unter Umständen unterschiedlich sein,
weil bei einem Kunden das Hauptaugenmerk auf etwas gaaanz anderem liegt, oder viel mehr vertieft wird.
(Datenbanktechnisch, Abfragen, etc...)
Desweiteren versuche ich immer meine Programme komplett in der Entwicklungsumgebeung auch bedienbar zu
halten, damit ich zu jeder Zeit alles Testen kann. Naja, mit gewissen Vorgaben natürlich.

Gibt es denn noch andere denkbare Alternativen?!?

[Union]

Wir haben dafür eine Art Db-Gestützte "Registry" verwendet (Selbstreferenzierte Tabelle mit Parent/Child). Diese lässt sich dann über Funktionen abfragen / setzen.

[Phoenix]

Auch Forms kann man ohne weiteres in DLL's auslagern... Und eigentlich ist das der Königsweg.

Hrm.. andere Alternativen...

Sehr, sehr, sehr unschön: Alle Funktionalitäten in ein Programm einbauen und je nach Konfiguration im Programmverlauf eben anstelle von Form X halt Form Y laden...

Problematisch wird es, wenn sich tatsächlich grundlegende Funktionalitäten ändern und man auch nur eine kleine Sonderbehandlung bei Kunde xyz vergisst: Das führt zu ganz unschönen Bugs, die extrem schwer zu lokalisieren sind und schlimmstenfalls sogar den Datenbestand gefährden.


Bevor man das anfängt ist es wirklich besser: Ein Build pro Kunde. Das kann man noch relativ gut mit automatisierten Build-prozessen handhaben, wenn man eine gemeinsame Codebasis hernimmt und die Änderungen für einen bestimmten Kunden per DIFF integriert.

Will heissen: Originalsourcen nehmen - Kundenänderung einbauen - diff gegen Original fahren und ablegen.

Beim Build-Prozess dann immer Originalsourcen hernehmen, build, diff Kunde 1 laufen lassen, build, originalsourcen hernehmen, diff Kunde 2 laufen lassen, build... Dauert etwas länger, und man muss natürlich aufpassen dass man wenn man den originalstand ändert auch alle diff's zu aktualisieren und ggf. in einigen Ständen nochmal von Hand nachzuarbeiten, aber das ist deutlichst weniger Buganfällig als alles in ein Projekt einzubauen.

*brrr* Da schaudert es mir schon bei dem Gedanken sowas verwalten zu müssen...

Nein: Die richtige und sichere und am einfachsten zu verwaltende Methode ist sicher die mit den in Module ausgelagerte DLL's. Und natürlich kannst Du auch in eigene DLL's reindebuggen und das aus der IDE raus lauffähig zu haben. Haben wir mit einem Projekt mit einem Gesamtumfang von ca. 1,6 Million Zeilen damals auch gehabt. Alles andere wäre projekttechnischer Selbstmord.

[dfried]

Zitat von Phoenix:

Auch Forms kann man ohne weiteres in DLL's auslagern... Und eigentlich ist das der Königsweg.

Aber nicht bei MDI-Anwendungen, da gehts dann vernünftig nur mit BPL's!

[Luckie]

Man könnte auch mit Compiler-Switches Arbeiten. Da sollte man aber aufpassen, dass man da nicht die Übersicht verliert.

[shmia]

Zitat von Phoenix:

Sehr, sehr, sehr unschön: Alle Funktionalitäten in ein Programm einbauen und je nach Konfiguration im Programmverlauf eben anstelle von Form X halt Form Y laden...

Das ist aber der Weg, den wir erfolgreich gehen.
Es gibt eben zunehmend mehr Optionen, die steuern wie sich das Programm verhalten soll.
Allerdings wird von uns nicht jeder Firlefanz eingebaut, sondern vorher nachgebohrt,
warum ein Kunde diese oder jene Funktion haben möchte.
Wenn man verstanden hat, warum ein Kunde etwas haben möchte, kommt man häufig auf eine allgemeingültige
Lösung.
Beispiel: der Kunde möchte in einem DB-Grid ein bestimmtes Feld nicht sehen; es stört ihn.
die allgemeine Lösung: ALLE DBGrids lassen sich nun konfigurieren auf Sichtbarkeit und Reihenfolge der Felder.
Die Konfiguration wird in einer INI-Datei gespeichert.

Für ganz "krumme Dinger" kann der Endkunde seine Spezialitäten in VB- oder Javascript abhandeln.
Dazu wird der Windows Scripting Host verwendet.
Es gibt vordefinierte Script-Funktionen mit Übergabeparametern.
Wenn die Scriptfunktion in der Datei vorhanden ist, dann wird sie ausgeführt.
Die Übergabeparameter sind COM/DCOM-Interfacezeiger; damit kann man relativ komplexe Dinge erledigen.

Code:

' VB-Script Beispiel
' Kunde möchte Lieferschein-Nr eingeben und mit der Orginal-Lieferscheinnummer vergleichen
' falls unterschiedlich muss ein Freigabepasswort eingegeben werden
' oder der Vorgang wird geblockt
Function NachAuftragLaden2(Application, Auftrag, AuftragDetail)
   Input = InputBox("Bitte Lieferscheinnr. eingeben", "Lieferscheinnr-Eingabe")
'   MsgBox "NachAuftragLaden (Eingabe: "& Input &")"
   if Auftrag.LieferNr <> Input then
      if Application.QueryUnlockPW = False then  'Freigabepasswort OK ?
'      err.Raise 99, "User Script", "Lieferscheinnummer und Passwort falsch!"
         Application.Exception.Init "Lieferscheinnummer und Freigabe-Passwort falsch!"
      end if
   end if

[franktron]

Also wir haben hier alle aufgelistenten wege schon versucht und sind dann am Ende ednlich bei DLLs angekommen.

Ich kann dazu nur saagen mit CompilerSwitches zu arbeiten bringt die IDE zu durcheinander weil sie nicht merh weis wass Sie debugen soll.

BPL mag schön sein hab aber mich leider nie richtig mit beschäftigt(werd ich wohl auch nie).

Für jeden Kunden ein eigenes Build (vergiss es) das bringt nur Ärger, änderst du was im MainProg und alle sollen es haben kannste alles ändern.

DLLs geht auch mit MDI man kann alles machen damit genau wie mit BPL, einzigster nachteil die DLLs sind recht gross weil alles in jeder DLL ist. der Grosse Vorteil ist es ist einfach man muss nicht gucken das alle Delphi BPLs da sind die man braucht und man hat alles getrennt.

Und nun was wir gemacht haben wir haben 2 Wegen in einem also einmal die DLLs und dann noch für kleine änderungen Switches im Code (keine Compiler Switches) eben für kleine anpassungen z.b. eine zusätzliches Feld im Kundenstamm dafür lohnt sich nicht der aufwand ein Extra Modul für den Kunden zu machen.

Und die DB da haben wir einen SQL Parser Geschrieben der Lokale SQL Files liest und dann die DB den Fiels anpasst.