Laden...

Entwurf eines eigenen Frameworks

Erstellt von andrgrau vor 14 Jahren Letzter Beitrag vor 14 Jahren 3.288 Views
A
andrgrau Themenstarter:in
22 Beiträge seit 2009
vor 14 Jahren
Entwurf eines eigenen Frameworks

Hallo zusammen,

ich bin neu in der C#/.NET Programmierung, komme bisher eher aus der reinen C-Welt und Java und muss mich nun berufsbedingt mit C#/.NET beschäftigen.

Kurze Projektbeschreibung:
Als erstes kurz was ich genau machen möchte/soll: Ich soll eine Art Framework erstellen, so dass später auf Grundlage von diesem Framework weitere Programme entwickelt werden können. Es handelt sich dabei um Programme, die ein bestimmtes Messgerät ansprechen, auf dem Tests ausgeführt werden und Ergebnisse zurückgeliefert werden. Ich selber muss keinen dieser Tests implementieren, ich stell nur das Rahmenwerk, das dafür notwendig ist, dass nicht jedes mal das Rad neu erfundenn werden muss - was bisher der Fall war. D.h. es werden später andere dransitzen und die jeweilige Test-spezifische Logik programmieren.

Überlegungen
Es wurde entschieden, dass eine Vorlage in Visual Studio 2005 erstellt wird, die alle benötigten Funktionalitäten bereitstellt und darin dann die eigentliche Test-Logik hinzugefügt wird und die GUI dementsprechend angepasst wird. Der Grund hierfür liegt v.a. daran, dass die späteren Test-Entwickler so alles in einer Solution haben, sich ihre GUI zusammenbauen können und "möglichst komfortabel" entwickeln können. Außerdem soll jeder Test-Applikation nur aus einer exe bestehen.
(Es stand auch noch zur Auswahl die Funktionen als DLL bereitzustellen, die vom eigentlichen Test eingebunden wird, da aber die GUI einige Elemente besitzt, die immer dabei sein müssen und nicht vergessen werden dürfen, wurde diese Idee verworfen. Außerdem war noch die Idee, dass Test-Programme Module/Plugins sind, die geladen werden. Dort war jedoch das Problem mit der GUI, da diese einfach zu designen sein sollte und es hätte vermutlich den zeitlichen Rahmen gesprengt, da dort noch keine Erfahrungen vorhanden sind.)

Architektur
Nachdem ich einige Tage im Internet recherchiert habe, v.a. auch hier im Forum, habe ich mir eine 3-Schichten Architektur überlegt:*Presentation Layer: Das Grundgerüst der GUI mit allen wichtigen Elementen, die immer vorhanden sein müssen. Diese kann dann in Hinblick auf den jeweiligen Test einfach erweitert werden. *Business Layer: Hier steckt die gesamte Logik drin, d.h. zum einen ein Interface für die Test-Logik, das später realisiert wird. Außerdem steckt hier die gesamte Logik "drumherum" drin, also Verbindungsauaufbau zum Geräte, kleine "Tools" wie Interpolation etc., ein Mechanismus zur Lizenszierung, Erstellung von Test-Reports. *Data Access Layer: Speicherung der Daten, v.a. in Form eines Projekts, in dem Test-Ergebnisse, Einstellungen und der Report gespeichert werden.

Fragen
Nach langer Vorarbeit nun zu meinen Fragen, ich hab ja auch einen Hintergedanken, warum ich hier schreibe 😉1.Macht meine 3-Schichten Architektur Sinn? Es wäre so, dass die GUI die Test-Logik aufruft und über Events dann informiert wird, wenn neue Ergebnisse vorliegen. Die Test-Logik (bzw. der gesamte Business Layer) kennt die zugrundeliegenden Daten und kann sie benutzen. Die GUI kann somit nicht direkt auf Daten zugreifen, sondern nur über den Business Layer. 1.In Java kann ich ja vieles über Packages strukturieren, ganz so "nett" erscheinen mir die namespaces nicht. Daher habe ich mit Ordnern eine eigene Aufteilung des Projekts versucht, um Chaos vorzubeugen. (siehe Bild im Anhang) 1.Logging soll auch Bestandteil sein, bei Java habe ich schon Erfahrungen mit AspectJ gemacht, macht es daher Sinn rein für das Logging AOP (z.B. rapier-loomer.NET) zu benutzen oder soll ich dann lieber auf ein Framework ala log4net setzen? (Hoffentlich löst das keine Glaubenskriegen jetzt aus ^^ ) 1.Noch sonstige Anregungen bzw. Hinweise?

Vielen Dank schon einmal für eure Hilfe und Anrgeungen!!!

49.485 Beiträge seit 2005
vor 14 Jahren

Hallo andrgrau,

verstehe ich es richtig, dass du so eine Art Template für Test-Projekte erstellst und die Testentwickler diese kopieren und als Basis verwenden? Wenn ja, würde das für sehr ungünstig halten.

Ich würde eine Plugin-Lösung bevorzugen. Die von dir genannten Gründe gegen Plugins überzeugen mich nicht. In Generic Manipulator Tool findest du sogar eine exemplarische Lösung, für das Problem, wie man GUI-Code im Plugin vermeidet und trotzdem eine plugin-spezifische Oberfläche bekommt.

herbivore

A
andrgrau Themenstarter:in
22 Beiträge seit 2009
vor 14 Jahren

Hallo herbivore,

danke für deine Antwort.
Ich weiß, dass diese Lösung bei weitem nicht die schönste ist, das Problem an der ganzen Sache ist jedoch, dass jede einzelne Test-Applikation sehr spezifisch ist. Bei der einen werden nur ein par Werte eingestellt, Tests durchlaufen und am Ende kommt eine Textdatei als "Ergebnis" raus. Bei einer anderen müssen verschiedene Graphen erstellt werden (teils über externe Programme), Test-Ergebnisse im der GUI dargestellt werden und im schlimmsten Fall noch ActiveX-Forms eingebunden werden, die exakt für dieses Gerät entwickelt wurden.
Die Leute, die später auf der Basis Tests-Applikationen entwickeln, sind größtenteils aus der Elektrotechnik, also haben wenig Erfahrung bei Softwareentwicklung und mögen es am liebsten ganz einfach haben: Visual Studio zum Erstellen der GUI.
Deswegen auch ein Template, so dass sie VS starten und anstatt eines leeren Projekts legen sie meine Vorlage an, die schon die wichtigsten Dinge bereithält.

Ich hoffe, das macht es etwas klarer, warum ich mich dafür entschieden habe.

2.187 Beiträge seit 2005
vor 14 Jahren

Hallo andrgrau,

herbivor hat hier recht. Das Projekt zu kopieren und zu ändern ist nicht sehr sinnvoll.

Die GUI kann man (im einfachsten fall) als UserControl implementieren, welches von der eigentlichen Form (aus dem Basis-Projekt) geladen und angezeigt wird.

Und das mit "nur einer exe" lässt sich
A) über .Netz lösen, welches mehrer Assemblies zu einerm zusammen paken kann.
B) oder man vewirft es einfach, da für das Ausführen einer .Net-Anwendung eh das gesamte Framework installiert sein muss (d.h. mit nur der *.exe kommt man egal wie man es dreth nicht besonders weit.

Ach ja: Wilkommen auf mycsharp.de!

Gruß
Juy Juka

A
andrgrau Themenstarter:in
22 Beiträge seit 2009
vor 14 Jahren

Hallo JuyJuka,

danke für die Begrüßung auf mycsharp.de 🙂

Die GUI kann man (im einfachsten fall) als UserControl implementieren, welches von der eigentlichen Form (aus dem Basis-Projekt) geladen und angezeigt wird.

Das könnte dann z.B. folgendermaßen aussehen: Ich implementiere mein gesamtes Framework mit allem, erstelle daraus dann eine exe/dll. Diese wird dann von dem eigentlichen Test-Projekt als Referenz hinzugefügt und kann somit ohne Probleme darauf zugreifen. Soweit alles klar.
In meinem Framework erstelle ich das Grundgerüst der GUI (Fenster, Menu, ...) und im Test-Projekt ist dann der Rest der Oberfläche als UserControl? D.h. ich würde aus dem Test-Projekt, das der Einstiegspunkt ist, die Form aus dem Framework starten und dann das UserControl dem Form hinzufügen?

Nur damit ich das richtig verstehe, bei GUI Design bin ich bisher weniger erfahren.

Zu meinem bisherigen Ansatz: Nicht dass das falsch verstanden wird, es soll zwar schon möglichst schön sein, jedoch muss ich aufgrund meiner fehlenden Erfahrungen bei solch einem Design einen Mittelweg finden, mit dem ich das Projekt in der vorgegebenen Zeit abliefern kann und später auch damit gearbeitet werden kann.
Zwar mag das Template nicht wirklich schön sein, ist aber bisher der bequemste Weg dafür, m.E. nach. Die eigentliche Hauptaufgabe an Programmieraufwand kommt ja eigentlich noch, die ganzen Funktionalitäten, die ich bereitstellen muss (wie oben erwähnt).

mfg

49.485 Beiträge seit 2005
vor 14 Jahren

Hallo andrgrau,

du hattest ja nach der Sinnhaftigkeit gefragt und diese habe ich aus meiner Sicht nach Bestem Wissen und Gewissen beantwortet. 😃 Das Problem bei einem Template ist die extreme Redundanz durch das Kopieren und die sich daraus ergebende schlechte Änder- und Erweiterbarkeit im Nachhinein.

Wenn du ein Framework schreibst, sollte das von den Testprojekten sauber getrennt sein. Ich denke nicht, dass ein Pluginsystem die Sache für die einzelnen Entwickler nennenswert erschweren würde. Selbst wenn man der Einfachheit wegen erlaubt, dass das GUI direkt im Plugin designet wird (z.B. als UserControl, das dann automatisch von der Host-Anwendung auf dem Form zusammen mit den Standard-Elementen platziert wird), wäre immer noch viel gegenüber der Template-Lösung gewonnen.

Nur damit ich das richtig verstehe

Ja, kannst du so machen.

herbivore

A
andrgrau Themenstarter:in
22 Beiträge seit 2009
vor 14 Jahren

Hallo herbivore,

ich geb dir ja auch Recht, dass die Template Methode nicht gut ist, wobei ich mir noch ein paar weitere Gedanken gemacht habe und mir einen Mittelweg dazu überlegt habe:
Ich packe den gesamten BL und DAL in das Framework und erstelle daraus eine DLL, die dann wiederum vom Test-Projekt benutzt wird. Das Test-Projekt lege ich in diesem Fall jedoch als Template an, so dass spätere Test-Entwickler hier ein gewisses Grundlayout haben, das sie benutzen müssen/sollen.

Nochmal auf meinen ersten Post bezogen:*Macht es Sinn (wie im angehängten Bild beschrieben), das Projekt so in Ordnern aufzuteilen? Dann habe ich kein heilloses Durcheinander mit den Klassen. *Logging: Sinnvoll nur wegen Logging AOP zu benutzen oder einfach log4net o.ä. benutzen?

mfg

2.760 Beiträge seit 2006
vor 14 Jahren

Macht es Sinn (wie im angehängten Bild beschrieben), das Projekt so in Ordnern aufzuteilen?

Ja durchaus. Mach ich auch immer.

Logging: Sinnvoll nur wegen Logging AOP zu benutzen oder einfach log4net o.ä. benutzen?

Ich benutze immer die Standard .Net-Klassen dafür (TraceListener etc.. aus dem System.Diagnostics.Debug-Namespace) aber die mögen dem ein oder anderen zu spartansich sein.

A
andrgrau Themenstarter:in
22 Beiträge seit 2009
vor 14 Jahren

Nachdem ich nun ein bisschen rumprobiert habe, habe ich mich jetzt (hoffentlich^^) endgültig für folgendes Szenario:

Das Framework ist die ausführbare EXE, die die gesamte "Logik" enthält, auf die ein Test zurückgreift. Außerdem ist dort auch das Form mit Menu etc.
Jeder Test ist eine DLL, der prinzipiell aus mind. einer UserControl besteht, die dann eben von der EXE geladen und dargestellt wird.
Es soll sich immer um nur eine EXE handeln, d.h. ich verwende das von JuyJuka vorgeschlagene Tool .Netz, um aus einer EXE und eine DLL nur eine EXE zu bekommen, wo alles enthalten ist. (.Net ist immer installiert!)

Da die EXE (das Framework) nicht weiß, welcher Test ihm beiliegt, muss ich die DLLs dynamisch laden. Aus diesem Grund sollte jeder Test immer gleich heißen, also "test.dll" zum Beispiel.
Reicht das dann aus, dass ich per Assembly.Load("test.dll") die DLL lade und eben verwende? (Hier gibts ja einige Artikel dazu, deswegen die Frgae zum prinzipiellen Vorgehen.)

mfg

2.187 Beiträge seit 2005
vor 14 Jahren

Hallo andrgrau,

Immer den gleichen Namen zu verwenden ist schlecht. Man soll die Tests ja unterscheiden können und so.
Mir fallen zwei bessere Lösungen ein:

  1. Alle Assemblies im Ausführungsverzeichnis (auch sich selbst) durchsuchen und alle Typen die von einem interface (ITest) oder einer bestimmten Klasse (TestUserControl) erben instanziieren. Falls man mehr als eine Instanz erschafft, muss man alle dem User anzeigen (ein Name-Property nicht vergessen) und er eines auswhälen. Wenn man nur einen findet fällt das natürlich weg.
  2. Über ein Konfigurationsdatei den AssemblieQualifiedName des auszuführenden Tests an das Framework übergeben (Activator.CreateInstanc(Type.GetType("..."),new object[]{})).

Falls noch zeit bleibt solltest du auf jeden fall noch versuchen UI und Test/BL auch für die Test trennen, so dass man ein allgemeinen Steuerelment hat (z.B. mit PropertyGrid) und wenn man will ein eigenes Entwerfen kann.

Ansonsten finde ich das Framework so weit gut, nicht zu viel und nicht zu wenig.

Gruß
Juy Juka

A
andrgrau Themenstarter:in
22 Beiträge seit 2009
vor 14 Jahren

Hallo JuyJuka,

danke für deine Antwort, als ich noch ein bisschen rumgespielt hab und auch den Artikel Plug-ins in C# auf Codeproject gelesen habe, kam mir das dann auch, dass ich noch ein Interface einbau, um zu testen, ob diese davon erben. War an sich eh schon geplant und jetzt habe ich noch einen Grund mehr, das so einzubauen.

Ich werde auf jeden Fall versuchen, dass auch im Test UI und BL getrennt bleiben, zumindest werde ich es so zur Verfügung stellen und hoffen, dass die späteren Test-Entwickler es auch einhalten 😉

Vielen Dank für eure Hilfe!!!

A
andrgrau Themenstarter:in
22 Beiträge seit 2009
vor 14 Jahren

Ok, ich muss jetzt doch noch einmal schreiben, da sich leider noch ein Problem aufgetan hat:
Es soll immer nur eine EXE sein, d.h. die Test-DLL soll in der EXE entahlten sein. Das erledige ich über .Netz und das funktioniert an sich ja auch über den -d Parameter, dass ich DLLs mit Assembly.Load("test.dll") laden kann. Das Problem ist nur, dass ich dann die DLLs nicht mehr suchen kann, wie wenn sie im selben Ordner liegen würden. Da die DLLs nicht alle immer gleich heißen sollen, sondern ich zur Laufzeit rausfinden will, welche der Test ist (Prüfen, ob von Interface geerbt).

Konkret ist dazu die Frage, ob es eine Möglichkeit gibt, nach DLLs zu suchen, die mit in die EXE gepackt wurden? Ich hab schon rumgesucht, bisher aber noch nichts dazu gefunden.

mfg

2.187 Beiträge seit 2005
vor 14 Jahren

Hallo andrgrau,

Hier für wäre ein neuer Thread nicht schlecht, da es ja ein konkretes neues Problem ist. [EDIT=herbivore]Siehe .Netz gepackte EXE: dll dynamisch laden[/EDIT]

Hast du schon versucht einfach das Programm selbst auch mit zu durchsuchen, vielleicht können die mit ,Netz eingebundenen Typen ja so gefunden werden (ich hab nie mit .Netz gearbeitet).

Gruß
Juy Juka

S
37 Beiträge seit 2007
vor 14 Jahren

Hallo Miteinander,

ich glaube in diesem Thread ist mein Anliegen am Besten aufgehoben.
Und zwar benötige ich Info zu eben genau dem Threadthema.
Kurze Erklärung, ich habe mitnerweile ein ganzes Sammelsorium von eigenen Assemblys (DLLs) welche jede für ihren Zweck existiert. Diese DLLs lassen sich in verschiedene Kategorien einteilen. Als Bsp. sieht die Ordnerstruktur in der die DLLs gespeichert sind so aus:

1.Firma
1.1.Technologie
1.1.1.Funktion
1.1.1.1.Unterfunktion
1.1.2.Funktion
...
...

Nun ich würde gerne ein Framework oder SDK erzeugen, indem ich alles unterbring. Also wie
Systems.Windows.Forms;
Firma.Technologie.Funktion;

Ich hab schon gegoogelt was das Zeug hält, aber iwie komm ich nicht weiter. Kennt jemand von euch ein Tutorial oder ähnliches, indem so etwas beschrieben wird? In der MSDN steht da zwar was von strongname und wie man DLLs veröffentlicht etc. aber so richtig schlüssig ist das mir nicht.

Ich danke euch schon mal

G. Stefan

1.815 Beiträge seit 2005
vor 14 Jahren

Hallo!

@stefan++:
Du hast doch schon als Beispiel System.Windows.Forms genannt, analog solltest du dein Framework aufbauen.
Je nach Technologie verwendest du eine Klasse, in welcher die Funktionen als Methoden abrufbar sind. Anschließend kannst du die dll als Verweis einbinden und die Klassen/Methoden verwenden.

Nobody is perfect. I'm sad, i'm not nobody 🙁

C
282 Beiträge seit 2008
vor 14 Jahren

Ich arbeite seit kurzem mit dem "Managed Extensibility Framework". Ich bin völlig begeistert und kann das nur weiterempfehlen.

http://mef.codeplex.com/

Die zusätzlichen Module können einfach nachgeladen werden, ohne das die sogenannte ".EXE" davon etwas von den Modulen weiß. Somit ergibt sich eine super Erweiterbarkeit in der Form, dass man einfach neue DLL's nachschieben kann, ohne die EXE neu zu schreiben.

S
37 Beiträge seit 2007
vor 14 Jahren

@Cannon: Das mit dem MEF klingt gut, werde ich mir mal genauer anschauen.

@tom-essen: Das bedeutet dann aber, dass schlussendlich nur eine Assembly erzeugt wird, welche sämtlichen Klassen aus den bisher bestehenden DLLs in einer Klassen-Methoden Struktur vereint. Soweit war ich gedanklich auch schon. Nun gut, wenn ich keine für mich bessere Lösung finde, wird das wohl der Weg sein.

Danke für die Antworten.

G. Stefan