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.... :stupid: 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!??! :gruebel:

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:

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:

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:

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.

[hanspeter]

Zitat:

Zitat von franktron

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.

Das ist der Grund, warum ich möglichst BPL vermeiden will.
Wie habt Ihr MDI aus Dll in den Griff bekommen?

Gruß Peter

[dfried]

Zitat:

Zitat von franktron

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.

Na, dann schick mir mal ein bisschen Beispielcode wie du das "Tabulator-Taste-Problem" sinnvoll gelöst hast?
Wir (und andere...) haben bisher keine vernünftige Lösung hierfür gefunden.
Mit Delphi 4 ging das noch wunderbar :-)

[kalmi01]

Moin, moin,

wir machen es schon seit sehr langer Zeit so, dass die Funktionen in einem allgemeinem Programm abgehandelt werden.
Alles, was kundenspez. sein könnte liegt in Scripten.
Je nach dem, an welcher Stelle sich das Prog. befindet, lädt es Script a, b, c, usw.
Auf diese Weise kann man auch ohne Compiler direkt vor Ort schnell etwas anpassen.

Wenn das richtig durchdacht ist, hat man nur wenige Scripts und je Kunden nur 1 kundenspez. Script.

[Jelly]

Skripte unter Delphi :gruebel:

BPL's sind im Prinzip wesentlich leichter zu handhaben unter Delphi, allerdings funktionieren die nur bei Programmen die mit gleicher Delphi Version erstellt werden... DLL's sind da unabhängiger.

[kalmi01]

Zitat:

Skripte unter Delphi :gruebel:

==> DelphiWebScriptII

[Jelly]

Ob das aber noch alles performant ist ?

[franktron]

Zitat:

Zitat von hanspeter

Zitat:

Zitat von franktron

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.

Das ist der Grund, warum ich möglichst BPL vermeiden will.
Wie habt Ihr MDI aus Dll in den Griff bekommen?

Gruß Peter

Hab das DLL Demo von Luckie genommen und dann auf meine bedürfnisse angepasst.

Und für das String problem habe ich FastMM4 benutzt

[ken_jones]

Wir verwenden ebenfalls so eine Art Script. D.h. unsere Lösung basiert auf Oracle und wir versuchen so viel wie nur möglich als PL/SQL zu implementieren.
Somit ruft Delphi die PL/SQL Skripte auf um die DB zu Ändern oder Resultate zu bekommen, etc.
Gleichzeitig sind alle SQLs in der DB. Somit können die meisten Änderungen vor Ort ohne Compilieren gemacht werden.

Die Formulare selbst werden über einen VisualConfigurator (leider Copyright unserer Firma) geändert. Es gibt aber Komponenten die Freeware sind und fast dasselbe können. Dort kann der Kunde zur Laufzeit das Formular ändern. D.h. er kann Felder verstecken, verschieben, umbenennen, etc. Kolonnen in Tabellen verschieben, vergrössern, etc.pp. Die Änderungen werden wiederum in der DB gespeichert.
Viele Formulare haben auch eine Tabcontrol drauf. Auf diesen Tabs können verschiedene Möglichkeiten der Erfassung drauf sein (Detailiert, Schnellerfassung, Änderungen,...) oder zusätzliche Funktionen (Tab1: Erfassung, Tab2: Details, Tab3: Replikation...). Durch DB Einträge wird gesteuert, welche(s) Tab(s) angezeigt werden sollen, pro Mandant, Kunde, Gruppe, etc.

Sämtliche Kundenänderungen in der DB werden mit einem "Individualisierungsflag" gekennzeichnet. D.h. wenn wir einen Major Update fahren, so werden alle nicht gekennzeichneten Prozeduren, PL/SQLs, etc. geupdated. Einziges Problem: Wenn das Update eine Änderung in einem SQL erzwingt, welches vom Kunden individualisiert wurde. Dann muss derjenige, der die Individualisierung vorgenommen hat, sich um das manuelle Updaten kümmern.

Das ganze Projekt ist in hunderte von DLLs aufgeteilt. (ERP Lösung, daher...)
Es ist bei über 800 KMUs im Einsatz und wir können das ganze super verwalten. Und durch die starke Auslagerung aller Funktionen in PL/SQL können wir das ganze Projekt viel einfacher mal in eine andere Sprache umsetzen.

Es gibt kein einziges Modul, welches in 2 Versionen (für Kunde A / Kunde B) daherkommt. Nur Module die speziell für einen Kunden geschrieben sind (Funktionen die NUR dieser Kunde braucht).
Sobald die Funktion für einen anderen Kunden auch interessant wird, gehts in den Standard über.

[dfried]

Zitat:

Zitat von franktron

Hab das DLL Demo von Luckie genommen und dann auf meine bedürfnisse angepasst.
Und für das String problem habe ich FastMM4 benutzt

Und die PlugIns sind dann auch MDI-Childs oder werden die modal aufgerufen?

[franktron]

Zitat:

Zitat von dfried

Zitat:

Zitat von franktron

Hab das DLL Demo von Luckie genommen und dann auf meine bedürfnisse angepasst.
Und für das String problem habe ich FastMM4 benutzt

Und die PlugIns sind dann auch MDI-Childs oder werden die modal aufgerufen?

Eigentlich beides habe eben Dialoge und MDI Childs (meist MDI Childs)

[kalmi01]

hallo ken_jones,

Zitat:

Die Formulare selbst werden über einen VisualConfigurator (leider Copyright unserer Firma) geändert. Es gibt aber Komponenten die Freeware sind und fast dasselbe können. Dort kann der Kunde zur Laufzeit das Formular ändern

kannst Du Beispiele nennen ?

Zitat:

Zitat von jelly

Ob das aber noch alles performant ist ?

wenn Funktionen in der EXE sind und nur die Konfig im Script, geht das schon.

OK, wem der schnellste Proz immer noch zu langsam ist, für den ist das nichts.

Wenn ein Prog so angelegt ist, dass es auch bei <1GHz Proz nocht akzeptabel läuft, sollte man keine Probleme haben, da erst compiliert wird und dann ausgeführt.

[Jelly]

Kannst Du denn mit den Skripten auf Klassen und Variablen deines eigentlichen Delphiprogramms zugreifen. Wie sieht es mit Datenbankbindung im Skript aus.

[kalmi01]

Zitat:

Zitat von Jelly

Kannst Du denn mit den Skripten auf Klassen und Variablen deines eigentlichen Delphiprogramms zugreifen.

über Wrapper können Skript und Exe komunizieren(gegenseitige Funktionsaufrufe).

Zitat:

Zitat von Jelly

Wie sieht es mit Datenbankbindung im Skript aus.

hab ich noch nicht ausprobiert.
Sollte aber auch über Wrapper funktionieren.

[Jelly]

Warum lagerst Du denn nicht die ganze Funktionalität direkt in eine eigene Klasse aus, anstatt umständlich über Skripte zu verfahren. Denn die Trennung hast Du ja so oder so, und musst kucken dass die einzelnen Module in das richtige Kundenprogramm reinrutschen.

[kalmi01]

Nicht ganz.

Skripte setzen wir in versch. Bereichen ein:

1.) Konfiguration, weil mehr Möglichkeiten (dynamischer), als bei INI-Dateien.
2.) Sachen, die der Kunde selbst ändern/anpassen darf/soll.
3.) Macro's/Macro-Aufzeichnung
4.) selbstmodifizierender Code

Spätestens bei 4.) wird's "hardcoded" ziemlich schwer, unübersichtlich und definitiv nicht mehr zu debuggen.

zu 1.): dynamische Strukturen dürfen sich während der Lebenszeit eines Prog's für die versch Releases ändern, Feste nicht. Oder sie wachsen ins Unendliche.

[ken_jones]

Zitat:

Zitat von kalmi01

hallo ken_jones,

Zitat:

Die Formulare selbst werden über einen VisualConfigurator (leider Copyright unserer Firma) geändert. Es gibt aber Komponenten die Freeware sind und fast dasselbe können. Dort kann der Kunde zur Laufzeit das Formular ändern

kannst Du Beispiele nennen ?

Siehe z.B. Runtime Design System 2.2
At runtime, your application users can do Moving Controls, Resizeing Controls, Deleting Controls, Creating Controls, Changing Property in the Object Inspector, Saving Controls and Loading Controls if you use the Runtime Design System.

Gibts wie Sand am Meer bei Torrys:
z.B.: Runtime Form Designer v.0.1 Beta

oder

Runtime Object Inspector

[mh166]

Zitat:

Zitat von kalmi01

Zitat:

Zitat von Jelly

Kannst Du denn mit den Skripten auf Klassen und Variablen deines eigentlichen Delphiprogramms zugreifen.

über Wrapper können Skript und Exe komunizieren(gegenseitige Funktionsaufrufe).

Im Entwickler 1.06 ist seite 39 ein interessanter Titel: "Die Schlange und das Orakel". Da gehts drum wie man per Python Delphiprogramme steuern kann. Und auch wenn ich keine Ahnung von Py hab, so sieht das für mich verhältnismaßig einfach aus...

Ich hoffe es is vertretbar mal zwei kleine Kästen daraus zu zitieren. Als Appetitmacher sozusagen. ;)

Zitat:

Zitat von Der Kasten 'Python installieren'

Um eine Verbindung zwischen Delphi und Python herzustellen, ist die Installation des Python-Interpreters [1] und von Python for Delphi [2] notwendig.
Beide Pakete besitzen ein Setup, mit welchem sich die Installation problemlos vornehmen lässt. Möchte jemand Python weitergehen benutzen, so ist noch das Paket Python for Win32 [3] zu empfehlen, mit welchem nahezu jede Aufgabe unter Windows mit Python erledigt werden kann; mithilfe dieser Erweiterung wird es sogar möglich, COM-Server in Python zu erstellen

Zitat:

Zitat von Der Kasten 'Was ist Python?'

Python [3] ist eine objektorientierte Programmiersprache, die von Guido van Rossum entwickelt wurde. Benannt wurde sie nach dessen Vorliebe für "Monthy Pythons Flying Circus". Python besitzt eine sehr klare Struktur und bietet eine umfassende Standarbibliothek. Zahlreiche im Web verfügbare Erweiterungen decken nahezu jeden Bedarf ab. Eine Stärke von Python ist die Möglichkeit den Interpreter in verschiedensten anderen Programmiersprachen einzubetten und so auf einfache Art und Weise zu erweitern. Ein prominentes Beispiel hierfür ist unter anderem OpenOffice.org. Mittlerweile existieren neben der in C geschriebenen Interpreterversion (CPython) auch Implementierungen in Java (Jython [4]) und .NET (IronPython [5]).

Die Links dazu:

[1], [2], [3], [4], [5]

Viel Spaß damit. Es lohnt sich sicher auch die o.g. Ausgabe - sofern nicht vorhanden - nachzubestellen. Gab auch nen interessanten Artikel über UML-Tools und noch vieles mehr :)

mfg, mh166