Laden...

[gelöst] Verwaltung von Utilityklassen

Erstellt von mosspower vor 15 Jahren Letzter Beitrag vor 15 Jahren 2.209 Views
mosspower Themenstarter:in
456 Beiträge seit 2007
vor 15 Jahren
[gelöst] Verwaltung von Utilityklassen

Hallo "Kollegen",

anbei ein Screenshot von der Ordnerstruktur meiner Utilityklassen. Die Struktur ist zusammengefasst in ein Library Projekt mit dem Namen Util. Nun ist es aber mitlerweile so, dass das Teil 2.9 MB groß ist (ohne bin und obj Ordner). Das blöde ist jetzt, dass wenn man mal schnell eine Consoleanwendung ect. macht und 3 oder 4 Methoden aus dem Utilitypack braucht, dass ich immer das Projekt eingebunden habe, was aber jetzt schon sehr nach mit Kanonen auf Spatzen aussieht. Naja, was ich vermeiden möchte ist, dass ich immer den Code rauskopiere. Ich könnte jetzt das nochmals "zerbröseln" und aus jedem Oberordner, z.B. Database, DLL, EDI ect ein eigenes Projekt machen und die dann einbinden, nur habe ich hier auch schon "Überkreuzungen" 😛, da die sich teilweise auch widerum gegenseitig referenzieren würden. Wie habt ihr das denn gelöst? Wie sieht das bei euch aus?

Da fällt mir gerade noch was ein. Ich komme ursprünglich von der Java-Schiene, da war ich es gewohnt, einen Ordner src zu machen und da die Sourcecodes. Hätte ich gerne auch gemacht in C#, nur das Problem ist, wenn ich in VS Klassen neu anlege, dann müsste ich immer den Namespace manuell anpassen (Löschen von src in den Namespaceangaben). Gibt es hier einen Workaround? Vielleicht kann ich irgendwo VS mitteilen, dass meine Sourcen in einem bestimmten Ordner sind (wie auch bei Eclipse) - leider habe ich sowas bisher nicht gefunden. Ist halt immer noch für mich irgendwie ungewohnt, wenn bin und z.B. lib auf gleicher Ebene liegen, wie die Klassenpakete. Gibt es hier eine Lösung?

OK, das war es dann schon wieder.
Danke schon mal im Voraus für eure Antworten und Anregungen.

Gruß

1.346 Beiträge seit 2008
vor 15 Jahren

Du kannst aus den Utility-Klassen die Namespaces entfernen und dann kannst du sie einfach in ein anderes Projekt reinkopieren.

pdelvo

5.742 Beiträge seit 2007
vor 15 Jahren

Hallo mosspower,

lege eine "große" Utility Projektmappe in VS an.

In diese kannst du dann deine Utility Klassen in diversen Projekten, die sich natürlich auch gegenseitig referenzieren können, verteilt packen.

Dann kompilierst du das ganze einmal.

Ab sofort kannst du dann die DLLs mit den Utility Klassen, die du brauchst, einbinden. Um das noch zu vereinfachen, kannst du alle "Utility-DLLs" im GAC registrieren.

Mit dem Sourcecode würde ich unter keinen Umständen direkt arbeiten - ansonsten viel Spaß beim Durchführen von Änderungen...

2.187 Beiträge seit 2005
vor 15 Jahren

Hallo mosspower,

Die Ordner-Struktur ist eigenlicht unwichtig. Interesant wäre jedoch die Klassen-Struktur. Dann kann man sagen, wie man die Klassen aufteilen kann.
Will hier winSharp93's aussage noch mal unterstreichen. Mach eine DLL draus und gut ist.

Gruß
Juy Juka

5.941 Beiträge seit 2005
vor 15 Jahren

Hallo mosspower

Ich würde Klassen die spezifisch sind bzw. spezifische Abhängigkeiten haben (bspw. Web oder Windows) jeweils in ein anderes DLL-Projekt kompilieren.
Jedoch würde ich nicht würd jeden Unterzweig eine neue DLL erstellen, das ist dann kaum mehr wartbar. (Ist schon, aber man machts nicht 😉)

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

1.433 Beiträge seit 2006
vor 15 Jahren

Hallo mosspower
Ich würde folgende Triage vornehmen, wenn Du die Utilities später noch verwenden willst.

  1. Allgemeine Utilities => als Common DLL kompilieren
  2. Web spezifische Utilites => als WebImplementation DLL kompilieren

etc.

Grüsse
Daniel
Space Profile
Wer nicht fragt, der nicht gewinnt

49.485 Beiträge seit 2005
vor 15 Jahren

Hallo mosspower,

die Meinungen gehen ja ziemlich auseinander. Das liegt vermutlich an mehreren Faktoren. Zum einen gibt es wirklich verschiedene Wege, die man einschlagen kann. Wichtiger ist aber vermutlich, dass es ganze unterschiedliche Arten von Utilities gibt und je nachdem, wie die konkrete Situation ist, bieten sich unterschiedliche Vorgehensweisen an.

Erstmal voirne weg: Utilities - also Hilfsklassen oder noch drastischer formuliert Hilfsfunktionen - sind oft oder sogar meistens nicht besonders objektorientiert aufgebaut. Aber gerade die Objektorientierung ist wichtig für eine gute Strukturierung. Insofern würde ich JuyJuka zustimmen. Die Projektstruktur sollte der Klassenstruktur folgen. Ich würde sogar noch einen Schritt weitergehen: Da sich sich eine gute Klassenstruktur normalerweise sinnvoll in Namespaces aufteilen lässt und auch andersherum eine gute Strukturierung der Namespaces eine gute Klassenstruktur begünstigt, sollte die Projektstruktur sollte der Namespaces-Struktur folgen.

Bei der Erstellung von Utilities fragt man sich leider oft: welche Funktionen kann ich gut gebrauchen. Man sollte aber fragen: welche Klassen sind so grundlegend und hilfreich, dass sich sie gut und oft wiederverwenden kann. Dann sollte man diese Klassen und ihre Beziehungen festlegen sowie deren Aufteilungen in Namespaces. Und erst danach sollte man sich um die Methoden der Klassen kümmern (ich spreche hier absichtlich nicht mehr von Funktionen).

Namespaces sollten nicht zu klein sein. Wenn die einzelnen Namespaces nur wenige Klassen enthalten, hat mal vermutlich etwas falsch gemacht. Man bedenke, dass z.B. System.Windows.Forms (fast) alle Control-Klassen für Windows-Forms-Anwendungen enthält. Wenn man eigene Controls schreibt, sollten diese entsprechend auch alle in einen gemeinsamen Namespace.

Die Meinungen gingen ja auch an dem Punkt auseinander, ob es wartbar ist, wenn man jeden Namespace in eine eigene DLL übersetzt. Das ist sicher davon abhängig, wie groß die einzelnen Namespaces sind, weil davon natürlich abhängt, über wieviele DLLs wir reden.

Die Frage eine DLL vs. mehrere DLLs hängt auch davon ab, wie stabil die Utilities sind. Die Wartbarkeit wurde ja schon angesprochen. Das Problem sind dabei vor allem Änderungen an bestehenden Methoden/Properties, die schon in anderen Anwendungen benutzt werden. Wenn man diese ändert, muss man im Prinzip alle Anwendungen erneut testen, die diese benutzen. Dadurch das DLLs Versionsnummern haben, gibt es natürlich die Möglichkeit, dass die bestehenden Anwendungen weiterhin die bisherige DLL-Version benutzen und nur die neue Anwendung die neue Version. Aber spätestens, wenn man aus einer bestehenden Anwendung auch neu hinzugekommene Methoden benutzen will, muss man die neue DLL-Version benutzen und kommt (auch bei der Verwendung von Unittest) um ein erneutes Testen der Anwendung nicht herum.

Im Umkehrschluss bedeutet dass, dass Utility-Klassen besonders stabil sein sollten. Das heißt von Anfang an gut designet und möglichst geschlossen und vollständig. Nichts ist schlimmer, als jeden Tag zu ändern, was einem gerade in den Sinn kommt. Wenn man das nicht tut, sollte auch die Wartung in den Griff zu bekommen sein.

Die Frage GAC oder nicht kann man dagegen eindeutig beantworten. Grundlegende Assemblies, die von mehreren/vielen Anwendungen benutzt werden, gehören immer in den GAC.

herbivore

5.657 Beiträge seit 2006
vor 15 Jahren

Ich habe auch so einen Ordner mit lauter Hilfsklassen wie Collections, Matrizen usw.
Erfahrungsgemäß benötige ich für ein Programm meist nicht mehr als zwei oder drei Klassen daraus. Deshalb möchte ich ungerne eine utilities.dll in jedem Programmordner haben, in dem sämtliche Klassen definiert sind.

Deshalb binde ich die erforderlichen Klassen meist direkt in das Projekt ein, entweder per Referenz (die Datei bleibt im Utilities-Ordner) oder die Datei wird einfach in den Projektordner kopiert. Letzteres führt allerdings dazu, daß man u.U. mehrere Versionen einer Datei hat.

Der Namespace bleibt aber immer gleich, während der Programm z.B. im Namespace Program1 zu finden ist, sind die Helper-Klassen immernoch im Utilities-Namespace. So kann man die Dateiversionen jederzeit ersetzen und evtl. später immernoch in eine DLL auslagern.

Christian

Weeks of programming can save you hours of planning

S
443 Beiträge seit 2008
vor 15 Jahren

Ich möchte auch noch meinen Senf los werden ohne meinen Vorrednern zu widersprechen.

Ich habe mir bei meinem letzten grösseren Projekt (MVC) die Namespace und dll Aufteilung von Microsoft abgeguckt
datenbank Dinge liegen im Namespace FirmenName.Data und in der dll FirmenName.Data.dll
die Controls in FirmenName.Windows.Forms(.dll) etc.

Habe da zwar einige dlls zusammengebracht, aber es war eigentlich recht leicht wartbar, obwohl ich Anfangs noch an mehreren Stellen Baustellen fertigstellen musste.

mit Zirkelbezügen in den Verweisen hatte ich keine Probleme und wenn war es ein schlechtes Design, falls Du bei manchen Klassen nicht weist in welchen Namespace sie gehören, solltes Du die Klasse überarbeiten. Wenn man sich fragt "Wo passt sie am besten hin" riecht die Klasse auch schon eigenartig und sollte überdacht werden

mbg
Rossegger Robert
mehr fragen mehr wissen

Montag morgen ist die beste Zeit um eine erfolgreiche Woche zu beginnen

mosspower Themenstarter:in
456 Beiträge seit 2007
vor 15 Jahren

Hallo,

vielen Dank für die Beiträge, die Unterstütung und die Anregungen. Nach einer "ÜBER"-Schicht Refactoring schaut das bei mir nun so aus wie im Anhang. Ich habe eine Solution Common erstellt. Hier gibt es den Subordner Util. War wirklich Zeit, denn es stehen ein paar Projekte an. Ein Jahr später wäre das die totale Hölle geworden.

3.971 Beiträge seit 2006
vor 15 Jahren

Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...

2.187 Beiträge seit 2005
vor 15 Jahren

Hallo mosspower,

Du solltest deine Namen noch anpassen. Microsoft hat da einige sehr hilfreiche Richtlinien. Richtlinien für die Benennung

Außerdem solltest du dir auch für die Assemblies die Punkt-Notation angewöhnen:
Mosspower.Utileties.Dll
Mosspower.Utileties.Gdi
Mosspower.Utileties.UI
Mosspower.Utileties (Für Misc verwendet man einfach den Root-Namespace 😉 )
Mosspower.Utileties.Web
...

Gruß
Juy Juka

mosspower Themenstarter:in
456 Beiträge seit 2007
vor 15 Jahren

@JuyJuka,

vielen Dank für den Hinweis, habe mir aber im Laufe der Zeit angewöhnt, dass ich Abkürzungen, bzw. Eigennamen, wie z.B. HTML, URL, XML usw. immer groß schreibe und nie plural verwende (das war in Java auch schon immer so) ... Misc werde ich rausnehmen, danke für den Hinweis.

49.485 Beiträge seit 2005
vor 15 Jahren

Hallo mosspower,

habe mir aber im Laufe der Zeit angewöhnt, dass ich Abkürzungen, bzw. Eigennamen, wie z.B. HTML, URL, XML usw. immer groß schreibe und nie plural verwende

mir kam die Schreibung von Abkürzungen in der Form Html statt HTML zuerst auch sehr ungewohnt und merkwürdig vor, aber mittlerweile bin ich voll davon überzeugt und kann auch dir nur empfehlen, dich darauf einzulassen.

Klassennamen sollten normalerweise in der Einzahl, Namespace-Namen sollten normalerweise in der Mehrzahl benannt werden. Das hilft auf einfache Weise den Problemen aus dem Weg zu gehen, die sonst durch Klassen entstehen, die genauso heißen, die Namespaces. Daher kann ich auch das nur empfehlen.

herbivore

mosspower Themenstarter:in
456 Beiträge seit 2007
vor 15 Jahren

@JuyJuka,
@herbivore,

OK, ihr habt mich dann doch (fast!, bei pluralen Namespaces bleibe ich "eisenhart") überzeugt und ich habe die Utilities nochmal angepasst. Ich werde in Zukunft die Eigennamen, wie z.B. HTTP oder URL in der Pascal-Case-Schreibweise benutzen (warum das Mircrosoft selber nicht immer konsequent durchzieht, z.B. IHTMLElement oder HTMLElement in mshtml habe ich keine Ahnung). IO habe ich nicht übers Herz gebracht Io zu schreiben 😁 ... ich habe alle meine Enums, die ich gegenwärtig komplett wie Konstanten geschrieben habe (Name und Eigenschaften) auch gleich mit angepasst, alle Klassennamen und natürlich alle auch alle Methoden ... jetzt habe ich aber keine Lust mehr. Auch wusste ich nicht, dass man Projektnamen mit Punkt (.) vergeben kann und diese dann physikalisch so nicht "auf der Platte" liegen müssen - bin halt "Java-verseucht" 😉 ...

also, an alle, vielen Dank für die Hilfe und Unterstützung. Ich denke, dass ich jetzt endlich einmal "sauber" in diesem Bereich bin.

2.187 Beiträge seit 2005
vor 15 Jahren

Hallo mosspower,

IO habe ich nicht übers Herz gebracht Io zu schreiben 😄

Keine Sorge, ist auch Microsoft-Konform, da Abkürzungen von weniger als 3 Buchstaben komplett groß geschrieben werde sollen.

Gruß
Juy Juka