Modularer Programmaufbau

[Paul Exler]

Hallo,

ich beschäftige mich derzeit mit dem Aufbau einer neuen Software, die in naher Zukunft sehr umfangreich werden wird.
Diese Software arbeitet mit MDI-Fenstern.

Um zu verhindern das die Applikation, wie unser bisheriges Hauptprodukt, über 25 MB groß wird, möchte ich gerne seperate Module hierfür schreiben.

Alle MDI-Formulare werden von einem MDI-Basisformular abgeleitet, dass im Hauptprogramm verankert ist.

Und hier entsteht auch meine Frage: Gibt es eine Möglichkeit ein Formular zu erzeugen, dessen abgeleitetes Formular im Hauptprogramm steckt, aber das komplett in z.B. einer DLL oder einer BPL steckt?

Ich habe mir auch überlegt, dass es evtl. sinnvoll wäre die Formulare erst zur Laufzeit zu erzeugen und die Definitionen, wo welche Komponente auf dem Formular zu platzieren ist, in z.B. einer Datenbank abzuspeichern. Hierbei stellt sich aber für mich das Problem, dass ich nicht von vorne herein alle Units, die das Formular benötigt mit in die Applikation kompilieren will.


Über Lösungsansätze oder Anregungen wäre ich sehr dankbar


Besten Dank schonmal im Voraus

[Bernhard Geyer]

25 MB ist schon gewaltig? Wir haben hier ca. 20 Mannjahre entwickelt und kommen "nur" auf 14 MB - Mit Multi-DB-Support/Reporting/.... Und wir haben primär alles in eine Exe gepackt um der DLL/BPL-Hölle aus dem Weg zu gehen.

Hier wäre evtl. zu hinterfragen was denn die Exe so groß macht? Wird evtl. wenig Wiederverwendung (Business/GUI-Logik) betrieben und das Problem der großen Exe ist eher Hausgemacht?

[Bernd Schulz]

Hallo!

Mit einer soliden Versionsverwaltung kann man der BPL Hölle leicht entkommen.

Für Packages gibt es hier eine recht gute Anleitung:
http://entwickler-forum.de/showthread.php?t=28212

Vererbung etc. alles kein Problem mit Packages. Mit DLLs gabs hier soviele Problemmeldungen, dass wir das nie ausprobiert haben...

Die Packages unseres Verlagssystems (momentan ca. 80 Stück) haben so 30-400 Kb.

BYE BERND

[Paul Exler]

Man sollte vielleicht dazu erwähnen, dass unsere Exe-Datei nach der Benutzung von ASPack "nur" noch ~6MB groß ist. Bei uns stecken übrigens auch über 10 Mannjahre drin.

Worum es mir aber eigentlich geht ist die Entwicklung eines neuen Produktes, bei der ich einen möglichst optimalen Programmieransatz verfolgen möchte.

Nachdem ich mir einiges über das modularisieren durchgelesen habe, denke ich auch zunehmend, dass sich dies unter Delphi nur mit Problemen bewerkstelligen lassen würde.


Nun gehen meine Überlegungen weiter, ob es evtl. sinnvoll wäre das Produkt unter .Net zu programmieren. Hier lässt sich das ganze mit seperaten Assembly's wunderbar lösen. Allerdings kann ich mich mit Visual Studio 2005 nicht ganz anfreunden. Bei großen Formularen / vielen Zeilen Code wird die Entwicklungsumgebung sehr träge. Delphi 2007 hingegen scheint mir eine relativ gute und stabile Version zu sein. Mit der kommenden "Highlander"-Version wäre auch hier die Überlegung, ob man sich auf Delphi.Net stützt. Allerdings hab ich bedenken, ob dies so ein Schluss nach hinten wird, wie Kylix (a lá wir machen 2-3 Versionen und danach vergessen wir einfach, dass wir das mal als Tool angeboten hatten).

Oder meint Ihr es wäre sinnvoll mit dem schönen schnellen und stabilen Win32 Delphi eine einzelne Exe-Datei zu entwickeln um sich die ganzen .Net Probleme /Risiken zu ersparen?

Was meint Ihr? .Net mit VS / .Net mit Delphi oder doch lieber auf Modulisierung verzichten und stattdessen eine Delphi Win32 Applikation entwickeln?


Vielen Dank für jede Antwort

[Bernhard Geyer]

Man sollte vielleicht dazu erwähnen, dass unsere Exe-Datei nach der Benutzung von ASPack "nur" noch ~6MB groß ist. Bei uns stecken übrigens auch über 10 Mannjahre drin.

Und? wo ist das Problem. 6 MB stört doch nicht.

Worum es mir aber eigentlich geht ist die Entwicklung eines neuen Produktes, bei der ich einen möglichst optimalen Programmieransatz verfolgen möchte.

Da sollte die Entscheidung ob man nun DLL's/BPL's/Assemblies oder was auch immer verwendet oder alles in eine Exe packt m.E. nur eine untergeordnete Rolle spielen bzw. sehr spät in der Anaylse/Desing/Architekturphase kommen. Viel mehr sollten Grundsätzliche Entscheidungen über die Architektur entschieden sein wie: Browser-GUI: JA/Nein. Platformunabhängig mit Java/.NET/Qt/..., .....

Nachdem ich mir einiges über das modularisieren durchgelesen habe, denke ich auch zunehmend, dass sich dies unter Delphi nur mit Problemen bewerkstelligen lassen würde.

Dem wiederspreche ich. Ob nun ein Exe oder viele DLL's/BPL's/Assemblies vorliegen sagt noch nichts über eine (sinnvolle) Modularisierung aus.

Nun gehen meine Überlegungen weiter, ob es evtl. sinnvoll wäre das Produkt unter .Net zu programmieren....

Das wäre m.E. eines der geringsten Aspekte die ich für oder gegen einen .NET-Port sehe.

Oder meint Ihr es wäre sinnvoll mit dem schönen schnellen und stabilen Win32 Delphi eine einzelne Exe-Datei zu entwickeln um sich die ganzen .Net Probleme /Risiken zu ersparen?.

Wie schon gesagt. Das Problem von DLL/BPL/Assembly sollte kein Grund für oder gegen .NET sein. Es gibt viele ander Aspekte die man betrachten sollte. Evtl. ist ja dann Java oder Qt die No. 1.

Was meint Ihr? .Net mit VS / .Net mit Delphi oder doch lieber auf Modulisierung verzichten und stattdessen eine Delphi Win32 Applikation entwickeln?

Ich esse lieber Äpfel als Biren. Genaus ist es (bei deiner Fragestellung) bezüglich Modularisierung und entscheidung Ja/Nein zu .NET oder Win32.

[Paul Exler]

Hallo Herr Geyer,

Vielen Dank für Ihre ausführliche Antwort.

Und? wo ist das Problem. 6 MB stört doch nicht.

An und für sich haben Sie recht, was die Größe angeht. Überlegungen die zur Diskussion über eine evtl. Modalisierung geführt hatten, waren der Overhead, den unsere Applikation mit sich bringt. Wäre es modualisiert, könnte man jedem Kunden seine eigenen Module zur Verfügung stellen.
Desweiteren ist unser Projekt mit etwa 400 Formularen alles andere als Übersichtlich geworden. Wir hoffen durch eine entsprechende Modualisierung die Übersichtlichkeit steigern zu können.

Ob nun ein Exe oder viele DLL's/BPL's/Assemblies vorliegen sagt noch nichts über eine (sinnvolle) Modularisierung aus.

Sehr wohl! Wenn Sie meinen ersten Post gelesen haben, werden Sie feststellen, dass ich eine Basisklasse benötige für meine MDI-Childs in einer MDI-Anwendung. Die MDI-Childs sollten bei der gewünschten Lösung ausgelagert sein. Wie dies mit Exe-Dateien lösbar sein soll, ist für mich fremd, weshalb ich zuerst einmal ausgehe, dass dies keine praktikable Lösung für mich ist. DLL's bringen viele Probleme mit sich (wie z.B. auch Herr Schulz bereits erwähnt hatte). Mehrere User hatten hier von Problemen, auch oft in Bezug mit MDI-Fenstern, berichtet.


Plattformunabhänigkeit ist für uns kein wichtiger Punkt. Da wir vor haben mit DataAbstract (für die Datenbankanbindung) zu arbeiten, wäre sowohl .Net als auch Delphi denkbar.
Ich versuche momentan nur die Vor- und Nachteile für/gegen eine Modualisierung abzuwegen.

[Bernhard Geyer]

An und für sich haben Sie recht, was die Größe angeht. Überlegungen die zur Diskussion über eine evtl. Modalisierung geführt hatten, waren der Overhead, den unsere Applikation mit sich bringt. Wäre es modualisiert, könnte man jedem Kunden seine eigenen Module zur Verfügung stellen.

Wie hoch ist den der Kundenspezifische Teil? Evtl. sollte man über ein Plugin-Schnittstelle nachdenken. ist besser als x Verschiedene Versionsstände zu haben.

Desweiteren ist unser Projekt mit etwa 400 Formularen alles andere als Übersichtlich geworden. Wir hoffen durch eine entsprechende Modualisierung die Übersichtlichkeit steigern zu können.

Ob nun diese in einer Exe liegen oder auf 20 BPL verteilt vereinfacht nicht die übersichtlichkeit. Hier ist eher angesagt ob diese Formulare nicht oft was ähnliches mache und per Redesign nicht zusammengefaßt werden können.

Sehr wohl! Wenn Sie meinen ersten Post gelesen haben, werden Sie feststellen, dass ich eine Basisklasse benötige für meine MDI-Childs in einer MDI-Anwendung. Die MDI-Childs sollten bei der gewünschten Lösung ausgelagert sein. Wie dies mit Exe-Dateien lösbar sein soll, ist für mich fremd, weshalb ich zuerst einmal ausgehe, dass dies keine praktikable Lösung für mich ist. DLL's bringen viele Probleme mit sich (wie z.B. auch Herr Schulz bereits erwähnt hatte). Mehrere User hatten hier von Problemen, auch oft in Bezug mit MDI-Fenstern, berichtet..

Und wenn du alle 4 Wochen feststellst das du eine weiter Methode in der Basis-Unit benötigst? Dann mußt du alle BPL's neu kompiliern und hoffen das keiner eine alte BPL einspielt. Und man kann auch mit "0815"-DLLs Plugins machen. MDI hab ich nicht probiert da wir das nicht haben. Aber sonst geht es (mit einigen Tricks) auch DLL-GUI-Elemente in Exe-Formularen.