Hi,
ich schreibe gerade an der nUpdate Administration und implementiere die soweit neu.
Nun habe ich einige Klassen, sagen wir
Bisher hatte ich die Architektur so gehalten, dass beim Instanziieren eines neuen Dialogs in einem Dialog diese Daten einfach über den Konstruktor mitgegeben werden. Das hat mir dann aber nicht mehr gefallen, weil's imho irgendwo redundanter Code ist. Somit habe ich mir nun folgendes gebastelt:
Das ist so der Grundriss. Ist also 'ne Singleton-Klasse, die die wichtigen Instanzen der Klassen enthält, die ich dann von überall aus z. B. mit
Nun weiß ich aber auch nicht, ob das so die saubere Art ist und ich das so lassen sollte.
Ich habe hier noch eine Basisklasse für die Dialoge liegen (
Was meint Ihr?
Grüße
ich schreibe gerade an der nUpdate Administration und implementiere die soweit neu.
Nun habe ich einige Klassen, sagen wir
TransferManager
, Logger
, UpdateFactory
, ..., welche dann die Datentransfers, Logs, Updatepakete etc. verwalten.Bisher hatte ich die Architektur so gehalten, dass beim Instanziieren eines neuen Dialogs in einem Dialog diese Daten einfach über den Konstruktor mitgegeben werden. Das hat mir dann aber nicht mehr gefallen, weil's imho irgendwo redundanter Code ist. Somit habe ich mir nun folgendes gebastelt:
C#-Quellcode
- namespace nUpdate.Administration.Application
- {
- internal class Session : Singleton<Session>
- {
- /// <summary>
- /// Gets the active <see cref="UpdateProject"/> of the <see cref="Session"/>.
- /// </summary>
- internal UpdateProject ActiveProject { get; private set; }
- /// <summary>
- /// Gets the <see cref="Administration.UpdateFactory"/> of the <see cref="Session"/> for managing updates.
- /// </summary>
- internal UpdateFactory UpdateFactory { get; private set; }
- /// <summary>
- /// Gets the <see cref="PackageActionLogger"/> of the <see cref="Session"/> for the package history.
- /// </summary>
- internal PackageActionLogger Logger { get; private set; }
- /// <summary>
- /// Gets the <see cref="Administration.TransferManager"/> of the <see cref="Session"/> for data transfers.
- /// </summary>
- internal TransferManager TransferManager { get; private set; }
- /// <summary>
- /// Gets the <see cref="Sql.SQLManager"/> of the <see cref="Session"/> for managing statistics entries.
- /// </summary>
- internal SQLManager SQLManager { get; private set; }
- /// <summary>
- /// Gets the <see cref="Proxy.ProxyManager"/> of the <see cref="Session"/> for managing proxies.
- /// </summary>
- internal ProxyManager ProxyManager { get; set; }
- private Session()
- { }
- /// <summary>
- /// Initializes the <see cref="Session"/> with the specified <see cref="UpdateProject"/>.
- /// </summary>
- /// <param name="project">The <see cref="UpdateProject"/> of the <see cref="Session"/>.</param>
- internal void Initialize(UpdateProject project)
- {
- ActiveProject = project;
- UpdateFactory = new UpdateFactory(project);
- Logger = new PackageActionLogger(project);
- TransferManager = new TransferManager(project);
- SQLManager = new SQLManager(project);
- ProxyManager = new ProxyManager(project);
- }
- // Vielleicht dann später eher noch einen Flag, der jeweils beim Abrufen einer Property geprüft wird.
- internal void Terminate()
- {
- ActiveProject = default(UpdateProject);
- UpdateFactory = null;
- Logger = null;
- TransferManager.Dispose();
- TransferManager = null;
- }
- }
- }
Das ist so der Grundriss. Ist also 'ne Singleton-Klasse, die die wichtigen Instanzen der Klassen enthält, die ich dann von überall aus z. B. mit
Session.Instance.UpdateFactory.PushUpdate(...)
aufrufen kann und die ist dann statisch im Projekt verfügbar, ohne, dass beim Öffnen des Dialogs zwangsläufig jedes Mal was weitergegeben werden muss.Nun weiß ich aber auch nicht, ob das so die saubere Art ist und ich das so lassen sollte.
Ich habe hier noch eine Basisklasse für die Dialoge liegen (
BaseDialog
), von der alle erben. Könnte man damit vllt. was basteln? Eine Art Zwischenschicht (Klasse), die die Dialoge jeweils verwaltet und dabei die Daten (also das Projekt) automatisiert übergibt, wurde mir auch schon vorgeschlagen, sodass ich damit meine Dialoge instanziieren könnte und schon alles hätte. Somit könnte ich auch alles durch die Oberklasse vorschreiben und jeweils einfach benutzen.Was meint Ihr?
Grüße
#define for for(int z=0;z<2;++z)for // Have fun!
Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose!
Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da
Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose!
Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da