GUI und Logik in verschiedene DLLs?

[Angel4585]

Hallöchen

In einer Gruppe von 10 Leuten bearbeiten wir in unserm Studium ein Projekt.
Ein Programm welches mit verschiedenen Algorithmen eine Lösung zu einem Problem finden soll.

Jetzt haben wir uns zum einen gedacht, die Algorithmen per DLL einzubinden, was auch alle sehr anspricht.
Die Frage ist folgende:
Jeder Algorithmus hat unterschiedliche Startparameter und benötigt unter Umständen individuelle Abbruchbedingungen.
Einem Genetischen Algorithmus kann man ja beispielsweise mitgeben, wieviele Generationen es insgesamt geben soll.
Ein Parameter den es bei anderen Algorithmen unter Umständen nicht gibt.

Deshalb möchten wir auch eine GUI per DLL einbinden (einfach ein Dialog oder ein Panel).

Was sagen die Profis:
Sollte man GUI und Logik in die selbe DLL stecken (algo.dll) oder in unterschiedliche (algo.logik.dll und algo.gui.dll)?
Und mit welcher Begründung?

[Sir Rufo]

Das ist gelinde gesagt absoluter Unfug.

Ein und dasselbe Problem hat per Definition eine Beschreibung, denn ansonsten beschreibe ich ein anderes Problem. Ergo kann (nein muss) der Aufruf gleich sein.

Das die Algorithmen evtl. mal mit Arrays oder Listen oder verketteten Listen oder whatever arbeiten ist natürlich richtig, aber das gehört schon zur Lösung und damit zum Algorithmus.

[Angel4585]

Das Problem ist ja auch immer das selbe.
Nur der Weg der zur Lösung des Problems führt ist ein anderer und hat daher verschiedene Aufrufparameter.

Einmal wird ein Genetischer Algorithmus verwendet, einmal eben kein Genetischer und dann nochmal ein ganz anderer.
Und gewissen Dinge sind bei den Algorithmen dann eben unterschiedlich.
Aber das Problem ist trotzdem das selbe.

[Sir Rufo]

Dann lässt es sich auch mit dem gleichen Aufruf beschreiben.

[Angel4585]

Muss ja identisch sein, sonst könnte man nur schwer ein Pluginsystem realisieren. Der Aufruf ist sowas wie
function StartSearch(opts : Pointer):TResult; Der Pointer geht halt auf ein Objekt oder Struct, welches je nach Algorithmus unterschiedliche Attribute hat.
Die Attribute benötigen eine GUI. Und da man nicht weis welche Algorithmen noch kommen und was die brauchen, kommt die GUI in eine DLL.
Edit: Die Frage ist aber doch: GUI und Logik trennen?

[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