Whiz-zarD

Für gewöhnlich fängt man bei einer Konsolenanwendung damit an, die Main-Methode selbst zu implementieren aber hast du dir mal die Main-Methode einer WinForms- oder WPF-Anwendung angeschaut? Die besteht nur aus drei Zeilen Code. So sieht sie z.B. bei einer WPF-Anwendung aus: public static void Main() { WpfApplication1.App app = new WpfApplication1.App(); app.InitializeComponent(); app.Run(); } Eine WPF-Applikation wird instanziiert, initialisiert und gestartet. Mehr passiert in der Main-Methode nicht und so sollten bestmöglich auch Konsolenanwendungen aussehen. Wenn du nur etwas ausprobieren möchtest, kannst du gerne so viele statische Methoden benutzen, wie du möchtest. Wenn das Tool aber produktiv genutzt werden soll, dann sollte man schon darauf achten, schon von Anfang an sauber zu entwickeln, denn aus Erfahrung heraus bleibt es nicht bei diesen 50 Zeilen, sondern das Tool wird immer weiter ausgebaut und ehe man sich versieht, wurden aus diesen 50 Zeilen plötzlich 1.000 und mehr Zeilen. Dann hat man nicht nur eine Datenbank, sondern zwei unterschiedliche, die dann zwei Log-Dateien erstellen und die Datei A.csv soll in die erste Datenbank und B.csv in die zweite und vielleicht möchte man dann noch die Logging-Informationen über eine Weboberfläche darstellen, weil der Kunde kein Zugriff auf die Log-Dateien hat, etc, etc, etc... Als weiteren Tipp geben ich dir auf den Weg, dich mit den SOLID-Prinzipien auseinanderzusetzen. Wenn man sie schon einigermaßen versteht und versucht, sich daran zu halten (oft ist es echt schwer, eine Lösung zu finden, die nicht gegen die Prinzipien verstößt), der entwickelt schon automatisch halbwegs vernünftigen Code und bitte: Schreib Unittests. Und wenn er es nicht kann, der Lehrer sollte es können, denn er kennt Java. Microsoft hatte sich damals bei der Entwicklung von C# viel von Java inspirieren lassen und beide Sprachen sind vom Aufbau sehr ähnlich. Ich hab früher auch hauptsächlich mit Java entwickelt. Seit einigen Jahren aber hauptsächlich mit C# und der Übergang von Java nach C# ging fließend.

Na ja, ich arbeite inzwischen seit einigen Jahren als Softwareentwickler und das, was ich schon in einigen Firmen an Code gesehen habe, geht echt unter keine Kuhhaut. Da schreiben selbst Entwickler, die 20+ Jahre Berufserfahrung haben, den allergrößten Mist an Code, den man sich nur vorstellen kann. Da werden Design Patterns auf abstruse Art- und Weisen oder sogar komplett falsch implementiert oder viele haben selbst nach 20 Jahren die Objektorientierung nicht verstanden und schreiben weiterhin spaghetticode wie in alten C-Zeiten. An der Software, wo ich jetzt arbeite, hat man statische Klassen aus Faulheit verwendet. Damit man die Klassen nicht instanziieren braucht, hat man sie statisch gemacht (yeeaah! Man spart sich eine Zeile Code...). Hier wurde Mikro-Optimierung auf die Spitze getrieben und von solchen Klassen gibt es hunderte und diese Klassen sorgen in Unittests immer wieder für Probleme, weil z.B. die Methoden Queries an die Datenbank schicken. Der Unittest ist dann von der Datenbank abhängig. Also testet man im Unittest nicht mehr die Methoden an sich, sondern schon komplexe Programm-Strukturen auf einen Schlag. Das Problem ist nun, dass man von statischen Klassen nicht erben und somit nicht mocken kann. Martin Fowler hatte diesbezüglich mal ein Blog-Eintrag geschrieben. Sein Beispiel ist aber relativ trivial. Stell dir mal vor, du hast im Code hunderte solcher Klassen, die hunderte von Abhängigkeiten besitzen, weil man laufe der Jahren die Klassen immer um weitere Methoden ergänzt hat und die Klassen nun mehrere Tausend Zeilen beinhalten. Ist ja auch so schön einfach, einfach statische Klassen zu erweitern ... Mir persönlich geht es auch eher darum, dass du ein gespürt dafür bekommst, wo die Probleme bei statischen Methoden/Klassen liegen und dass man schon wissen sollte, wann dieses Schlüsselwort angebracht ist und wann nicht. Nur weil man die Syntax versteht, heißt es noch lange nicht, dass man auch sauberen Code schreiben kann und das finde ich viel wichtiger als so manches andere aber das bekommt man von Firmen nicht so richtig beigebracht, weil man lieber aufgrund des Zeitdrucks lieber schmutzigen Code schreibt, der zwar jetzt schnell geschrieben werden kann und somit kostengünstig ist aber spätestens in einem halben Jahr hohe Kosten verursacht, weil der Code unwartbar ist.

Aus eigener Erfahrung gebe ich dir den Rat Die Interop-Schnittstelle nicht zu verwenden! Du handelst dir damit mächtig viele potenzielle Fehler ein. Selbst Microsoft rät von diesem Weg ab. Ein weiteres Problem ist, dass die Architektur ab Excel 2013 sich grundlegend geändert hat, sodass man gar nicht mehr sicher mit der Interop-Schnittstelle arbeiten kann. Früher war es so, dass man immer einen separaten Prozess gestartet hat, über den man arbeiten konnte. Inzwischen wird aber nur ein Prozess gestartet. Führt man also ab Excel 2013 new Excel.Application(); aus, so erhält man intern immer den selben Prozess. Die Properties ActiveSheet oder ActiveWorkbook funktionieren dann nicht mehr korrekt, wenn man nebenbei noch an einer weiteren Excel-Datei arbeitet. Man merkt aber erst beim Speichern, dass da irgendwas schiefgelaufen ist. Darüber hinaus ist auch die Interop-Schnittstelle extrem langsam und während die Excel-Datei erstellt wird, kann man auch die Copy/Paste-Funktion nicht mehr benutzen, weil die Interop-Schnittstelle darüber die Daten nach Excel Transferiert. Wenn du Excel-Dateien erstellen möchtest, dann verwende eine Bibliothek dafür, wie z.B. EPPlus. Das hat auch den Vorteil, dass man von einer Excel-Installation unabhängig ist, da Excel nicht benötigt wird.

Das ist ein sehr schlechtes Beispiel! Das verstößt gegen das Single-Responsibility-Prinzip! Die Mitarbeiter-Klasse hat dann plötzlich zwei Aufgaben: Zum einen repräsentiert es ein Mitarbeiter und zum anderen zählt die Klasse auch noch die Anzahl der Mitarbeiter. Die Mitarbeiter sollten in einem Repository gehalten werden und wir fragen das Repository nach der Anzahl. Schon mal es durchaus vorkommen kann, dass man temporär einen Mitarbeiter erstellen möchte, der aber wiederrum später gelöscht wird. Dadurch kann es zu schlimmen Seiteneffekte kommen, wenn die temporären Mitarbeiter-Klassen gezählt werden. Allgemein sollte man mit static sehr vorsichtig sein. Man sollte wissen, was man da tut. Statische Variablen/Methoden sind schlecht zu mocken, daher sollte man sie zugunsten des Unittests vermeiden. Statische Variablen braucht man echt sehr selten und zwar so selten, dass mir nicht mal ein gescheites Beispiel einfällt. In allen Projekten, die ich inzwischen gesehen habe, wo statische Variablen benutzt worden waren, führten sie irgendwann zu massiven Problemen. Statische Methoden brauche ich eigentlich höchstens nur bei Singletons oder Factory-Methoden. Außerdem gäbe es noch die Möglichkeit Mikro-Optimierungen zu betreiben und zwar wenn ich weiß, wenn eine private Methode unabhängig vom Zustand der Klasse ist, dann deklariere ich sie als private static. Dann wird die Methode nur ein mal im Speicher gehalten. Das Problem mit static ist, wenn sich dahinter Logik verbirgt und ein anderes Ergebnis liefert. Beispiel: DateTime.Now Diese statische Eigenschaft gibt pro Aufruf immer ein neues DateTime zurück. Wenn man nun eine Methode testen möchte, die DateTime.Now aufruft, wird man in Schwierigkeiten kommen, einen gescheiten Unittest zu schreiben, dessen Ergebnis reproduzierbar ist, da DateTime.Now nicht reproduzierbar ist. Man fängt dann also an DateTime irgendwie zu mocken. - Warum sollte sich der Umsatzsteuersatz nie ändern? - Die Matrikelnummer eines Studenten gehört dem Studenten, also darf diese nicht statisch sein! - Eine bestimmte RGB-Farbe wäre eine Konstante. - Pi ist ebenfalls eine Konstante. - Ablauf- und Erstellungsdatum gehören zum Lebensmittel und sind somit nicht statisch! Diese Beispiele sind also allesamt falsch und nicht zur Nachahmung empfohlen!

Hallo, liegen die Daten (mehrzahl von Datum) wirklich als String/(n)varchar in der Datenbank? Das macht doch überhaupt keinen Sinn ... Da die Millisekunden fehlen, wenn sie 0 sind, wenn du ToString() aufrufst, sieht es für mich aus, als würden die Daten in einem spezifischen Date-Format vorliegen. Dann kannst du auch einfach die Methode GetDateTime() aufrufen, was deutlich eleganter ist, da man sich den ganzen String-Kram schenken kann. DateTime zeitstempel = reader.GetDateTime(0); mfg Whiz-zarD PS: Die Zeichen : und . müssen nicht escaped werden.