GUI und Logik in verschiedene DLLs?

[sx2008]

Betrifft die Frage jetzt C#?
Dann sprechen wir von Assemblies (was gegenüber normalen DLLs ein grosser Unterschied ist).

Wie man seinen Code über versch. Assemblies verteilt hängt zunächst von den Abhängigkeiten zwischen den Klassen und Namespaces ab.
Eine Abhängigkeit sollte möglichst nur in eine Richtung gehen.

@Sir Rufo:
ich vermute bei dem Projekt sollen viele unterschiedliche Algorithmen demonstriert werden ohne dass eine konkrete Anwendung vorliegt.
Wenn man z.B. Quicksort vorführen möchte, dann bräuchte man vor dem Start die Anzahl der Elemente.
D.h. jeder Algorithmus braucht eine kleine Form/Frame (GUI) mit dem man die Parameter setzen kann.
Eigentlich müsste man auch noch die Ergebnisse visualisieren, sonst würde die Demo wenig Sinn machen.

>>Sollte man GUI und Logik in die selbe DLL stecken?
Falls die Logik nicht in anderen Projekten genutzt werden soll,
wäre eine gemeinsame Assembly günstiger.

[Angel4585]

Also es geht um C#, ja.
Ich muss gestehen, dass ich mich mit C# und Assemblies (noch) nicht auskenne.
Aber ein Studium ist ja da um zu lernen

Es sollte halt möglich sein, einem beliebigen entwickler, der sich dafür interessiert, eine Schnittstelle zu bieten selbst einen Algorithmus für das Problem zu entwickeln und diesen per DLL einzubinden.
Es sollte dann ein Tab/Reiter/Dialog für den neuen Algorithmus angezeigt werden.

[Sir Rufo]

Ok, dann müssen wir das mal etwas anders aufdröseln

Es gibt ein Hauptprogramm, dass die Plugins lädt und jedem Plugin einen Tab (mit einem Container) zur Verfügung stellt.
In diesem Container kann das Plugin dann je nach Gusto einen Einstellungsseite zur Verfügung stellen.

Die zu verarbeitenden Daten (also das Problem für sich) sind allerdings für alle Plugins gleich. Somit ergeben sich 3 Funktionalitäten die die Plugin-Dlls anbieten müssen:

1. GetPluginName
2. YourParentHandle( aHandle )
3. SolveProblem( ProblemDefinition )

Das Hauptprogramm fragt die DLL nach dem Plugin-Namen und erstellt ein Tab mit dem entsprechenden Container.
Der Handle dieses Containers wird an das Plugin zurückgegeben. Mit diesem Handle kann das Plugin nun die eigene Einstellungsseite oder was auch immer anzuzeigen.
Um das Problem zu lösen ruft das Hauptprogramm nun einfach SolveProblem des Plugins auf.

Damit sollte die Frage eigentlich beantwortet sein ...

[Angel4585]

Genau so dachte ich mir das auch

Frage war wie gesagt nur ob man Logik und GUI in verschiedene DLLs auftrennen sollte.
Aber dann kommt man vermutlich nur durcheinander und GUI liegt in Version x und Logik in Version y vor.

Vielen Dank an euch

Edit: Anstatt GetPluginName würde ich GetPluginInfo nehmen

[Sir Rufo]

Zitat von Angel4585:

Frage war wie gesagt nur ob man Logik und GUI in verschiedene DLLs auftrennen sollte.

Das Hauptprogramm sollte nur die Plugins ansprechen.

Ob das Plugin die benötigte GUI nochmals auslagert ... who cares, soll jeder Entwickler machen wie er will.

Absolutes NoGo: Das Hautprogramm muss sich zum Plugin noch das passende GUI-Plugin suchen