AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Anwendungs-Startup -- Konzepte?!

Ein Thema von s.h.a.r.k · begonnen am 28. Dez 2011 · letzter Beitrag vom 29. Dez 2011
Antwort Antwort
Seite 1 von 2  1 2   
Benutzerbild von s.h.a.r.k
s.h.a.r.k

Registriert seit: 26. Mai 2004
3.159 Beiträge
 
#1

Anwendungs-Startup -- Konzepte?!

  Alt 28. Dez 2011, 00:56
Guten Abend zusammen,

ich stehe gerade vor dem Problem, wie genau man eine Anwendung hochfahren lassen kann und welche Punkte dies denn alles betrifft. Im allgemeinen frage ich hier nach Ideen von euch und will auch über eine Idee von mir diskutieren. Ziel des Ganzen soll es dann irgendwann mal sein, ein einheitliches Framework zu basteln, welches für nachzu alle Anwendungstypen (VCl-Anwendung, Konsolenanwendung, Service etc.) anwendbar ist -- in so fern das überhaupt möglich ist.

Zu klären wäre zuvor noch der Zustand "vollständig gestartet": ich stelle mir bei einer normalen VCL-Anwendung den Zustand vor, in dem der Benutzer das Hauptformular sieht, d.h. bezogen auf z.B. die Delphi IDE, eben das IDE-Fenster, oder bei Microsoft Word auch das Eingabe-Fenster mit der Ribbonleiste. Ebenso kann man dies auf Konsolenanwendungen und Dienste übertragen: der Zustand, bei dem die erste Eingabe möglich ist bzw. die erste Aufgabe, für die die Anwendung erstellt wurde, abgearbeitet wird. Natürlich kann man das hier noch sehr weit fassen, aber ich denke, dass nun in etwa klar ist, um was es geht. Solltet ihr hierzu Anmerkungen haben, so lasst es mich gerne wissen.

Welche Sachen fallen nun an, bis sich die Anwendung im "vollständig gestarteten Zustand" befindet? Bitte vervollständigt diese Liste, wenn euch dazu noch etwas einfällt!
  • SplashScreen ein- und ausblenden: Hierzu hat sakura einen Thread geliefert, der sehr interessant ist. Ich hatte das bisher immer so gelöst, dass ich im Hauptthread den SplashScreen angezeigt und in weiteren Threads den Startup gehandelt habe.
  • Log-Komponente einrichten
  • Allgemeine Konfigurationen laden (Registriy, INI, DB, XML etc.): Ich lagere die Konfiguration in eine separate Klasse, die als Datenhalter agiert und von Factories und sonstigen Klassen abgefragt werden kann.
  • DB-Verbindung aufbauen: Hier versuche ich eine Verbindung zur Datenbank aufzubauen, scheitert dies versuche ich dies mit Hilfe des Users zu fixen, z.B. falsch eingegebene Zugangsdaten, oder bringe eine entsprechende Fehlermeldung.
  • Basis-Daten aus der DB laden: Hierunter ist zu verstehen, dass ich quasi bei der Anzeige des SplashScreens schon mal das aufwendige Laden von Daten abhandeln will, sonst muss ich dem Nutzer nochmals einen Ladebildschirm zumuten.
  • DLLs/Plugins laden
Diese Sachen tauchen bei meinen Anwendungen jedenfalls andauernd auf. Daraus leite ich ab, dass ich teilweise aufeinandere aufbauende Teile laden muss. Daraus entstand dann die Idee, dass ich einen allgemeinen CommandProcessor baue, der beim Start lediglich Commands ausführt. Jedes Modul bekommt dann, in so fern es für den Start relevant ist, eine Command-Klasse "zugewiesen". Ein Beispiel:
  • SplashScreenShowCommand
  • LoadConfigurationCommand
  • ConnectToDatabaseCommand
  • LoadDataFromDataBaseCommand
  • CloseSplashScreenCommand
Ich habe schon bewusst auf die Reihenfolge geachtet, allerdings nicht auf mögliche Parallelität. Und zwar müssen die Commands ja in einer sinnvollen Reihenfolge ausgeführt werden, da die DB-Verbindung ja Einstellungen benötigen könnte, die vom Konfigurationsobjekt kommen, ebenso kann ich den SplashScreen erst nach erfolgreicher Beendigung des letzten Commands ausführen. Auf der anderen Seite können aber auch manche Module parallel geladen werden -- leider fällt mir hierzu gerade kein Beispiel ein

Daraus resultiert jedenfalls, dass ich zwischen den Commands Abhängigkeiten einbauen muss, sodass der CommandProcessor das entsprechend beachten und automatisch parallel ablaufende Commands erzeugen kann. Hierzu fällt mir nur ein, dass jede Command-Klasse eine ID und eine "required Commands"-Eigenschaft erhält -- Eventuell kann man dies auch über Klassen-Attribute erledigen. Über diese Eigenschaften steuert der CommandProcessor dann alles.

Nun, wie aber läuft das mit der Registrierung der Command-Klassen/-Instanzen beim Processor ab? Hier brachte mich Stefan Glienke auf die ganz nette Idee, das ganze vollautomatisch über Klassen-Attribute laufen zu lassen und so via RTTI alle Klassen und deren Attribute auszulesen. Ist eine Klasse von einem speziellen Typ (z.B. TStartupCommand) abgeleitet oder wird ein gewisses Interface (z.B. IStartupCommand) implementiert und wird ein spezielles Attribute verwendet, so ist dies eine Command-Klasse, welche beim Start instanziiert und ausgeführt werden muss -- das einzige, was der Entwickler hier noch machen muss, ist die "Execute"-Methode der Command-Klasse zu implementieren. Über die Attribute sollen sich dann auch noch diverse Einstellungen der Commands steuern lassen -- Beispiel: Ein Command-Klasse muss zwei mal instanziiert werden, mit jeweils unterschiedlichen Einstellungen.

Ich hoffe, dass ihr nun ein Bild davon habt, was ich mir unter einem Start einer Anwendung so vorstelle. Natürlich ist das Konzept darauf ausgelegt, komplexe Starts sinnvoll zu managen, weshalb dieses für kleinere Projekte eher flach fällt, aber auch genutzt werden können soll -- daher so viel (beinflussbarer) Automatismus wie möglich.

So, spätestens an dieser Stelle würde mich interessieren, wie ihr dieses Konzept findet UND wie ihr eure Starts organisiert? Habt ihr Verbesserungsideen? Oder gibt es einen Punkt, den ich gar nicht beachtet habe und der das Konzept schon im Kern scheitern lässt?
»Remember, the future maintainer is the person you should be writing code for, not the compiler.« (Nick Hodges)
  Mit Zitat antworten Zitat
Benutzerbild von Mavarik
Mavarik

Registriert seit: 9. Feb 2006
Ort: Stolberg (Rhld)
4.076 Beiträge
 
Delphi 10.3 Rio
 
#2

AW: Anwendungs-Startup -- Konzepte?!

  Alt 28. Dez 2011, 02:16
hmm

Ich sehe die Notwendigkeit nicht...

SplashScreen... mag nicht schlecht sein, falls die Programm Initialisierung länger dauert...

Die meißte Zeit wir mit Sicherheit in den Init-Teilen der Units "verbraten"... Also ist das auch bei jedem Programm anders...

Mavarik
  Mit Zitat antworten Zitat
Furtbichler
(Gast)

n/a Beiträge
 
#3

AW: Anwendungs-Startup -- Konzepte?!

  Alt 28. Dez 2011, 09:00
Also ein einheitliches Startverhalten ist schon eine feine Sache, zumal die einzelnen Operationen voneinander abhängen. Aber wozu denn Threads?

Meine Anwendungen bestehen eigentlich immer aus einem Datenmodul und einem Hauptbild (klar, und 10000 Dialogen). Das Datenmodul wird im Konstruktor des Hauptbildes instantiiert. Die Dialoge erst, wenn ich sie benötige.

Wenn ich unbedingt einen Splash brauche, dann nehme ich ihn und lasse jedes einzelne Modul, das meint, beim Hochfahren etwas melden zu müssen, meinem Splash mitteilen 'Nächster Schritt: Foobar'. Wenn ich die Anwendung das erste mal durchlaufen habe, weiss ich auch, wie viele Schritte es waren und kann dann beim nächsten Mal einen Fortschrittsbalken anzeigen. Das geht automatisch. Animierte Splash-Screens mache ich erst, wenn ich mehr als 10 Kopien meiner Anwendung verkaufen sollte.

Das Datenmodul wird zuerst einen Logger instantiieren und Konfigdaten einlesen. Danach wird dann ggfs die Datenbank angesprochen oder eine Datei eingelesen oder sonstwas.

Wenn das DM fertig mit initialisieren ist, kann das Hauptbild weitermachen (das DM wurde ja im Konstruktor des Hauptbildes aufgerufen).

Im OnShow des Hauptschirms starte ich einen Timer, der das Splash nach 500ms schließt. Sieht schicker aus.
  Mit Zitat antworten Zitat
neo4a

Registriert seit: 22. Jan 2007
Ort: Ingolstadt
362 Beiträge
 
Delphi XE2 Architect
 
#4

AW: Anwendungs-Startup -- Konzepte?!

  Alt 28. Dez 2011, 09:24
Ich fürchte, dass Du Dir mit einem Command-Processor nur eine zusätzliche Abstraktionsschicht einfängst, ohne das eigentliche Problem (lange Ladezeit des Programms) zu lösen.

Vielleicht ist es ein pragmatischerer Weg, erst einmal zu modularisieren, indem man alle Funktionsbausteine per Dependency Injection verwaltet. Du weißt ja, dass dabei sich die Klassen zuerst einmal nur beim DI-Container registrieren und erst bei Bedarf/Anforderung instanziiert werden. Je nach Aufbau der App kann das schon einmal zu einer Verteilung der Initialisierungszeiten führen.

Ist die App erst einmal so modularisiert, kann man sich jeden einzelnen Baustein einzeln "vornehmen" und schauen, inwieweit sich dessen Initialisierung mit halbwegs vertretbaren Aufwand auslagern lässt.
Andreas
  Mit Zitat antworten Zitat
Benutzerbild von jaenicke
jaenicke

Registriert seit: 10. Jun 2003
Ort: Berlin
8.504 Beiträge
 
Delphi 10.4 Sydney
 
#5

AW: Anwendungs-Startup -- Konzepte?!

  Alt 28. Dez 2011, 09:26
Meine Lösung für den Anwendungsstart sieht so aus, dass ich die einzelnen Module ebenfalls aufteile und parallelisiert laden lasse. Dabei gibt es definierte Abhängigkeiten ähnlich denen von Windows Diensten. Diese werden geprüft und ggf. auf deren Ladeende gewartet. Sobald ein Modul angefordert wird, wird dessen Priorität in der Warteschlange erhöht. Dabei werden solche Module bevorzugt, die als für eine Reaktion der GUI notwendig markiert wurden.

Auf die Weise kann ich das Hauptformular bereits anzeigen bevor alle Module fertig geladen sind. Wird dann eine noch nicht geladene Funktion angefordert, wird deren Start priorisiert, aber in der Regel laden die Module einfach im Hintergrund weiter während der Benutzer die Basisanwendung bereits bedient.

So konnte ich bei einer Anwendung, die vorher 3 Minuten zum Start brauchte, die Startzeit bis der Nutzer im Hauptfenster ist auf ca. 2 Sekunden verringern. Bis alles fertig geladen ist dauert es nun rund 4 Minuten, weil die Organisation der Module usw. etwas Zeit kostet. Die Anwendung lässt sich aber auch direkt nach dem Start bereits ohne größere Verzögerungen bedienen.
Sebastian Jänicke
Alle eigenen Projekte sind eingestellt, ebenso meine Homepage, Downloadlinks usw. im Forum bleiben aktiv!
  Mit Zitat antworten Zitat
Benutzerbild von s.h.a.r.k
s.h.a.r.k

Registriert seit: 26. Mai 2004
3.159 Beiträge
 
#6

AW: Anwendungs-Startup -- Konzepte?!

  Alt 28. Dez 2011, 11:56
Danke schon mal für eure Antworten! Ja, ich mag einen animierten SplashScreen, daher arbeite ich auch mit verschiedenen Threads. Parallelität aber auch daher, da es einen Geschwindigkeitsvorteil bringen kann. Und warum sollte ich meinem CommandProcessor keine Threads beibringen, wenn Dinge parallel laufen könnten? Wenn ich eine so allgemein Lösung implementieren kann, dass sie auf fast beliebige Szenarios anwendbar ist, ist das doch nur ein Vorteil? Klar, ich handle mir hier etwas Komplexität ein, aber ich komme schon fast nicht mehr ohne Threads aus.

@jaenicke: Die Idee, die du da verfolgst ist doch relativ interessant. Ich habe bisher allerdings noch keine so lange Initialisierungsphase(n) zu bewältigen Hast du dir dafür ein universell zu nutzendes Framework geschrieben? Oder hast du das spezielle auf dein Problem angepasst? Wie hast du die Abhängigkeiten zwischen den Modulen gelöst?
»Remember, the future maintainer is the person you should be writing code for, not the compiler.« (Nick Hodges)
  Mit Zitat antworten Zitat
Benutzerbild von jaenicke
jaenicke

Registriert seit: 10. Jun 2003
Ort: Berlin
8.504 Beiträge
 
Delphi 10.4 Sydney
 
#7

AW: Anwendungs-Startup -- Konzepte?!

  Alt 28. Dez 2011, 13:34
Hast du dir dafür ein universell zu nutzendes Framework geschrieben? Oder hast du das spezielle auf dein Problem angepasst? Wie hast du die Abhängigkeiten zwischen den Modulen gelöst?
Die Abhängigkeiten werden in einem zentralen Verwaltungsobjekt über eine Klassenmethode registriert.

Derzeit ist das Konzept stark in dem Programm verwurzelt. Und hat auch ein paar unschöne Stellen. Wenn, dann würde es sich lohnen das zumindest teilweise neu zu schreiben. Bisher war das bei mir aber auch das einzige Programm, das das brauchte. Ich hatte aber schon vor in der Richtung weiter zu forschen. (In den Stunden zwischen 24:00 Uhr und 0:00 Uhr oder so vielleicht... hab einfach keine Zeit...)
Sebastian Jänicke
Alle eigenen Projekte sind eingestellt, ebenso meine Homepage, Downloadlinks usw. im Forum bleiben aktiv!
  Mit Zitat antworten Zitat
Iwo Asnet

Registriert seit: 11. Jun 2011
313 Beiträge
 
#8

AW: Anwendungs-Startup -- Konzepte?!

  Alt 28. Dez 2011, 13:44
Das einzige mal, als bei mir eine Anwendung 2-5 Minuten zum Hochfahren brauchte, war eine Adressdatenbank mit ca. 100.000 Einträgen im Spiel, welche eine Livesuche ("while you type") ermöglichte. Das Laden der 20MB und die Query selbst dauern nun mal.

Aber anstatt irgendetwas zu parallelisieren, habe ich die Ladezeit einfach verringert, und zwar auf 20 Sekunden: Einfach die Query optimiert und ADO etwas umgebogen. Das Laden wurde in einen Dienst ausgelagert. Der liest die Daten zum Programmstart ein und hält eine lokale Kopie (natürlich up-to-date) im Speicher. Die eigentliche Anwendung ist nunmehr in 1-2 Sekunden vollständig lauffähig, ohne das im Hintergrund noch etwas werkelt.

Ich kann mir keinen Fall vorstellen, bei dem eine Anwendung mehrere Minuten zum Initialisieren benötigt und wo man nicht durch scharfes Hinsehen (ohne Threads) ansetzen könnte. Was dann als notwendiges Übel übrig bleibt, kann von mir aus in einen Thread (oder in mehrere).

Weiterhin verstehe ich nicht, das man eine Anwendung schon bedienen kann, aber die notwendige(?) Initialisierung trotzdem 4 Minuten dauert, oder schaufelst Du präventiv alle eventuell notwendigen Daten in den Speicher?

Ich meine, ich kann mir auch parallel von 20 Anbietern jeweils 10 Tonnen Lebensmittel bestellen, obwohl ich ja eigentlich nur ab und an ein belegtes Brot essen will.

Ich will hier nix gegen Threads zum Programmstart sagen, denn schaden tut sowas ja nicht. Auch der Ansatz von Jaenicke ist vollkommen OK: Er vermeidet beim 'on demand fetching' meist das erstmalige Warten, da dies i.A. schon im Hintergrund erledigt wurde: Schick.

Aber bevor man zu irgendwelchen Tricks greift, um etwas schneller zu machen (Threads sind hier 'Tricks'), sollte man mal prüfen, ob das nicht eleganter geht. Ebenso wie Neo4a bin ich der Ansicht, das eine schlechte Performance zuforderst mit einer guten Struktur bekämpft werden kann.
  Mit Zitat antworten Zitat
Benutzerbild von Mavarik
Mavarik

Registriert seit: 9. Feb 2006
Ort: Stolberg (Rhld)
4.076 Beiträge
 
Delphi 10.3 Rio
 
#9

AW: Anwendungs-Startup -- Konzepte?!

  Alt 28. Dez 2011, 14:17
Die meisten Anwendungsprogramme werden doch einmal gestartet und laufen dann den ganzen Tag...

Dann dauert das jeben mal ein bischen...

Ist ne gute Möglichkeit um den Kunden mal wieder nen schnelleren Rechner zu verkaufen...

In der Zeit wo Du den Start optimierst, könntest Du etwas programmieren was der Kunde gebrauchen kann...

Mavarik
  Mit Zitat antworten Zitat
Benutzerbild von MGC
MGC

Registriert seit: 15. Mai 2008
Ort: Helsa
106 Beiträge
 
Turbo Delphi für Win32
 
#10

AW: Anwendungs-Startup -- Konzepte?!

  Alt 28. Dez 2011, 14:53
Also für mich hört sich das eher nach einem Konzept für Programme an, welche durch ein PlugIn-System beständig erweitert werden kann und man dennoch keine Performance-Einbußen im Startvorgang hinnehmen muss.
Für mich hört sich dieses Konzept sehr interessant an, da ich selbst Programme am Laufen habe, die aufgrund neuer benötigter Funktionalität mal eben nebenher erweitert werden müssen, ohne zum einen die Start-Performance durch neue PlugIns zu stören und zum anderen eben die Möglichkeit zu nutzen das Grundprogramm schnell an neue Labor-Situationen oder Updates unseres kommerziell erworbenen LIMS-Systems anzupassen und entsrepchend reagieren zu können ohne jedesmal das Hauptprogramm neu stricken zu müssen.
Dabei ist zu beachten das in vielen Betrieben sogar noch Single-Core-Prozessoren im Einsatz sein können.
Marc
Programmieren ist wie Chemie:
1. Wenn man alles einfach nur zusammenschmeisst kommt es zu unerwarteten Reaktionen.
2. Wenn es plötzlich anfängt zu qualmen, muss man eben noch mal von vorn anfangen.
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2   

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 11:21 Uhr.
Powered by vBulletin® Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf