Hallo Leute,

habe noch eine Frage bezüglich der Unterteilung einer Software in Module. Nach etwas herumstöbern habe ich nun erfahren, dass ich die Module als units oder dll-Dateien erstellen kann. Nun aber spezifisch zu meinem Fall:

Ich möchte eine Art WaWi erstellen und möchte die Software in Module unterteilen. Dabei sollen die einzelnen Module so programmiert werden, als wären sie eine Software für sich selbst. Z.B. Kundendatenverwaltung, Artikeldatenverwaltung und Lieferantenverwaltung. Der Kunde sucht sich die gewünschten Module aus, ich packe sie alle zusammen zu einem Programm und gebe es dem Kunden.

Ausserdem möchte ich die Module auch bei anderen Projekten nutzen können (also was anderes als WaWi).

Soll ich mich nun mit der Erstellung von dlls beschäftigen oder würde es ausreichen, wenn ich die einzelnen Module als units speichere und bei Bedarf in ein Projekt schmeisse?

Naja - mit dlls bist du auf jeden fall flexibler. wenn du ein anständiges plugin-system entwickelst, musst du nicht jedesmal, wenn du etwas integrieren willst, das komplette Projekt (und bei "einer art wawi" wird das groß, das projekt) neu kompilieren.

also besser DLLs.

Jetzt kommt eine ganz typische Anfängerfrage, aber wie genau kann ich mir das denn vorstellen? Was genau wird denn in den dll-Dateien hinterlegt, und wie bindet man die Module im Endeffekt an das Projekt? (also ich frage nicht nach technischen Details, sondern wie ich mir das - naja - bildhaft vorstellen?)

Zitat von davar:

Jetzt kommt eine ganz typische Anfängerfrage, aber wie genau kann ich mir das denn vorstellen? Was genau wird denn in den dll-Dateien hinterlegt, und wie bindet man die Module im Endeffekt an das Projekt? (also ich frage nicht nach technischen Details, sondern wie ich mir das - naja - bildhaft vorstellen?)

Dazu hat gibst eine gute Anleitung in der Code Library

Wie du dir das bildhaft vorstellst?

Eine DLL ist ein stück assemblercode. uns interessiert dabei im moment nur das codesegment. in diesem befinden sich funktionen, die können im prinzip alles machen - "hallo, welt" rufen, was zeichnen, oder sogar ein Windows-fenster erzeugen.

Deine Echse (auch ein Modul) nimmt sich nun eine DLL (loadmodule), denkt sich "hach, jetzt nehme ich mir mal eine funktion" (getprocaddress) "und die ruf ich jetzt auf".

naja, und das wars dann eigentlich auch schon.

Technisch mit allen Details ausformuliert gibts irgendwo (hier in der DP) n Tutorial von Olli. Englisch, PDF, under construction, aber die Grundlagen stehn da alle drin.

Blöd wird es, wenn die Echse der DLL daten geben will und andersrum. Denn Delphis Memorymanager ist so frei und gibt dem Hauptmodul (also der echse) und der DLL unterschiedliche Speicherbereiche zur Datenhaltung. Du musst dann z.B. die Unit Sharemem einbinden oder himitsus FastXMM.

Vielleicht sollte man ganz klar sagen, dass eine DLL nur Funktionen kennt.
Es gibt keine Klassen, Properties, Objekte, globale Variablen, Konstanten oder Events.
Wenn man nun meint, man könnte so einfach grosse Funktionsteile wie z.B. eine Artikelverwaltung in eine DLL verpacken, dann ist man auf dem Holzweg.
Das gesamte System wird später ein mehrfaches an Platz gegenüber einer einzige EXE-Datei benötigen, da die VCL mehrfach benötigt wird.

"Normale" DLLs sind daher ungeeignet für High-Level Dinge (Kundenstammverwaltung) aber sehr gut geeignet
für Low-Level Dinge wie Verschlüssung, Prüfsummenfunktionen, math. Statistikfunktionen, ....

Mit Packages werden diese Beschränkungen grösstenteils aufgehoben.
Packages sind "aufgebohrte" DLLs und haben aber auch einige Nachteile:
* sie sind gebunden an eine ganz bestimmte Compilerversion (also nur für Borlandprogramme geeignet)
* bei Änderungen im Interface müssen Anwendung und Packages neu kompiliert werden

Ich würde keine DLL's verwenden. Jedenfalls nicht für "normale" Funktionsblöcke. Überleg dir lieber ein vernünftiges sicheres Lizenzierungsverfahren. Wenn der Kunden Option A+B kauft dann bekommt er eine Lizenzdatei mit Option A+B. Diese sollte über Signaturen gesichert sein das er hier nichts ändern kann. Die Exe sollte ohne Debug-Infos ausgeliefert werden damit der Kunde nicht zu einfach diesen Schutz knacken kann. Intern ist es auf jedenfall angebracht die Funktionalität auf Module, Klassen etc. sinnvoll zu Verteilen.

Vorteil eine Exe:

- Keine Versionsprobleme bzw. es müssen nicht unnötig Schnittstellen kompatibel gehalten werden.
- Einfacher Versionsupdate durch eine Datei.

Nachteil:

- Ist halt u.U. ein paar MB groß.

Zitat von DGL-luke:

Technisch mit allen Details ausformuliert gibts irgendwo (hier in der DP) n Tutorial von Olli. Englisch, PDF, under construction, aber die Grundlagen stehn da alle drin.

Deutsch, älter und auch von mir

hmm.. Meinungsfreiheit kann auch schädlich sein, zumindest wenn jeder eine andere Meinung hat

Also soweit ich verstanden habe, wäre es für mich sinnvoller, die einzelnen Module als eigenständige Projekte zu programmieren (also Formulare und Code) und sie für jeden Kunden individuell zusammenzustellen. Wenn ich nur Funktionen in dlls packen kann, habe ich ja wieder mehr Arbeit an den Formularen.

Danke für die Antworten, werd mich auch mit den Tutos beschäftigen..

mfg

davar

Zitat von davar:

Also soweit ich verstanden habe, wäre es für mich sinnvoller, die einzelnen Module als eigenständige Projekte zu programmieren (also Formulare und Code) und sie für jeden Kunden individuell zusammenzustellen. Wenn ich nur Funktionen in dlls packen kann, habe ich ja wieder mehr Arbeit an den Formularen.

Na dann will ich mal meine Meinung kundtun.

Modularer Aufbau kann in der Programmierung beginnen, das ist richtig. Zwischen Units und DLLs muß jedoch grundsätzlich unterschieden werden!

Ich denke, daß die DLLs der bessere Weg sind. Wenn du ein gutes Plugin-System modellierst und dann jedes der "Programm-Module" als DLL auslieferst und dein Programm die Plugins aus dem Pluginverzeichnis immer kooperativ(*) lädt, dann bist du im Endeffekt besser dran, weil du:

• jederzeit neue oder aktualisierte Plugins an den Kunden ausliefern kannst
• nicht immer das Programm neu kompilieren mußt
• nur kleine einzelne Plugins aktualisieren und verteilen (Downloadkosten!) mußt, statt einer monolithischen EXE-Datei
• dem Kunden die Programmmodule einzeln anbieten kannst, Bsp: 1 Plugin kostet 150 EUR, 10 kosten 100 EUR pro Stück usw. ...
• selber nur jeweils ein Modul pflegen mußt
• Drittanbietern die API zu deinen Plugins verkaufen kannst
• später auch mal ein Programm-Modul in einer anderen Programmiersprache hinzufügen kannst ...

(*) damit meine ich, daß sowohl der Pluginloader als auch das Plugin entscheiden können ob das Plugin geladen bleibt. Kein Code sollte zur Ausführung kommen, bevor das Plugin als "funktionstüchtig" erkannt wurde.