Suchergebnisse

Hi, 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 hab…

Zitat von RodFromGermany: „Sozusagen werden die Instanzen per Default gebracht“Hier kann ich Dir jetzt leider nicht ganz folgen. Wie würdest Du das mit dem Interface angehen? Damit kontrolliere ich ja nur, was die Dialoge implementieren sollen. Oder verstehe ich Dich falsch? Grüße

Ich weiß, wie das Implementieren einer Schnittstelle funktioniert. Jedoch erschließt sich mir das nicht ganz. Wenn ich jetzt einem Dialog vorschreibe, was er haben muss (Logger, UpdateFactory usw.), dann kann ich das zwar in jedem ansprechen, aber initialisieren muss ich es ja trotzdem jedes Mal, wenn ich einen Dialog instanziiere. Grüße

OK, war mir nicht sicher, ob wir uns verstanden haben. Gut, das könnte man machen. Um es mal noch anders in den Raum zu stellen: Was denkst Du persönlich über die Idee mit der Singleton-Architektur? Was ich vielleicht noch erwähnen sollte, ist, dass es vmtl. vorteilhafter ist, dass so statisch anzubieten, damit das nicht nur in Dialogen benutzt werden kann, sondern auch in anderen Klassen. Wird wahrscheinlich auch mal nötig sein, aber frag(t)e mich halt, ob man da bei den Dialogen speziell noch …

Das sieht mir sehr gut aus. Ich werde mir die ganzen Entwurfsmuster ansehen und mal schauen, ob ich damit etwas basteln kann. Danke. Grüße

Ich habe mir jetzt mal Autofac angeschaut. Ist 'ne nette Sache, allerdings ist halt fraglich, ob ich dadurch einen entsprechenden Mehrwert habe, wenn ich zuerst die Scopes definieren und dann einzeln die Komponenten abrufen muss. Eine einfache ​static class wäre natürlich auch noch eine Idee (+ weniger Code). Ich weiß jetzt nicht, wie ich fortfahren sollte. Grüße

Ich will, dass ich zu Beginn die Administration ganz normal starte. Dann soll man über den Hauptdialog ein Projekt öffnen können und somit sollen in diesem Moment alle Daten initialisiert und zur Verfügung gestellt werden. Heißt, ich lade das und in dem Moment soll mit den Daten des Projekts jeweils eine Instanz zum Verwalten gebaut werden (UpdateFactory, Logger, TransferManager etc.), sodass ich das bearbeiten kann. Weil diese verschiedenen Funktionen jetzt in verschieden Dialogen bzw. Klassen …

Also DataSet o. ä. ist da wohl jetzt für meine Fälle am wenigsten geeignet... Ich habe mir nun privat auch noch ein paar Meinungen eingeholt und das statische Bereitstellen scheint soweit eine gute und einfache Lösung zu sein. Daher werde ich das vmtl. auch so benutzen, da IoC über Autofac imho keinen wirklichen Mehrwert bietet. Dependency Injection nutze ich ja bereits, wenn ich das so übergebe. Ist also schon eine derartige Verwendung, aber nicht die optimale. Die Frage ist dann nur noch, ob S…

Ne, muss sie nicht. Also wäre eine statische Klasse dann wohl die Wahl. Grüße

Zitat von ErfinderDesRades: „wenn ich Daten laden und bearbeiten möchte, schließt das für mich ein Dataset eiglich nicht von vornherein aus“Naja, weißte. Hier hängt drum herum noch ein bisschen mehr dran. DataSets sind von mir aus recht, wenn ich irgendwo wirklich mit Datenbanken rumhantiere und diese dann auch nur entsprechend bearbeite und wieder ablege. Davon abgesehen, dass ich aber selbst da das MySQL Entity Framework o. ä. verwenden würde. Nur geht's hier halt um wenig mehr drumrum. Meine …

Zitat von ErfinderDesRades: „Wenn nicht - interessierts dich?“Jo, klar. Kann man sich ja mal anschauen, wenn's das schon gibt, dass man da speziell mit DataBinding arbeiten kann. Bleiben werde ich dann wohl einfach bei der statischen Session-Klasse, aber ich lasse mich da gerne mal drauf ein. Grüße

Die Session-Klasse wird doch gar nicht serialisiert, nur das enthaltene UpdateProject, was 'ne normale struct ist. Grüße

Zitat von Nikx: „Wieso du hier ein struct nutzt sollst du mir aber auch mal erklären“Naja, im Prinzip war ich einfach der Meinung, dass die Klasse, die die Projekte repräsentiert, einfach ja nur Properties anbietet und eine Struktur ausreicht. Allerdings ist das da mit dem Setzen von Properties des ActiveProject in meinem Falle auch etwas blöd ("Cannot modify expression because it is not a variable"), sodass ich es nun wieder als normale Klasse behandle. Und Session ist eben die statische Klasse…