Whiz-zarD

Bei Pi und vordefinierte RGB-Farben (RGB-Farben allerdings nur bedingt. Siehe weiter unten) bin ich dabei, dass es Konstanten sind aber Matrikelnummer und Ablauf- und Erstellungsdaten (die mehrzahl von Datum) sind keine Konstanten. Offenbar vermischst du hier final (Java) bzw. readonly (C#) Variablen mit Konstanten, aber da gibt es einen großen Unterschied: Konstanten sind während des Kompilierens bekannt. Beim Kompilieren wird überall, wo die Konstante benutzt wird, gegen den konkreten Wert ausgetauscht. Darum können Konstanten auch nur integrierte Datentypen sein. Es läuft also erst mal ein Präprozessor, der die konkreten Werte ermittelt und diesen dann überall einfügt. Darum sollte man auch etwas vorsichtig mit Konstanten aus Drittbibliotheken sein. Wenn sich eine Konstante in einer Fremd-DLL ändern sollte, bekommt dein Code erst mal davon nichts mit, bis du dein Code neu kompilierst. Aufgrund dieser Schritte besitzt eine Konstante auch keine Variablenadresse. Variablen hingegen werden während der Laufzeit initialisiert und sind zur Kompilierzeit nicht bekannt. Das gilt auch für final bzw. readonly Variablen. Final/Readonly Variablen werden per Initialisierung oder per Konstruktor initialisiert. Ob man jetzt die Matrikelnummer oder Ablauf- und Erstellungsdatum wirklich final/readonly machen möchte, ist vom Design abhängig aber ich würde das eher nicht tun. Man schränkt sich dann doch sehr extrem ein. Man müsste dann diese Werte im Konstruktor reinreichen und das sollte man bei Geschäftsobjekten nicht machen. Die XML-Deserialisierung vom .Net Framework erwartet z.B. einen parameterlosen Konstruktor. Wenn du jetzt die Studenten aus einer XML-Datei lesen möchtest, würdest du dann schon Probleme bekommen, da die Matrikelnummer readonly wäre und somit über den Konstruktor mitgegeben werden muss. Auch gängige O/R-Mapper (wie z.B. (N)Hibernate, Entitiy Framework oder Dapper) erwarten einen parameterlosen Konstruktor. Vielleicht möchte man aber auch einfach mal einen Studenten erzeugen ohne eine Matrikelnummer. Dann wird man wieder Probleme bekommen. Man müsste dann wieder eine Factory-Methode schreiben, die einen Studenten mit einer Dummy-Matrikelnummer zurückgibt. Alles Einschränkungen, die man nicht möchte. Wann sollte man dann also readonly verwenden? Mir würden da spontan zwei Beispiele einfallen: z.B. die o.g. RGB-Farben. Da Konstante nur integrierte Datentypen sein dürfen, müsste man einen ganzzahligen Wert nehmen aber man besitzt vielleicht eine RGBColor-Klasse und man möchte über diese Klasse diverse Farben vordefinieren. Dafür bietet sich dann statische readonly Variablen an. Beispiel: public class RGBColor { public static readonly RGBColor Black = new RGBColor { Red = 0, Green = 0, Blue = 0 }; public static readonly RGBColor White = new RGBColor { Red = 255, Green = 255, Blue = 255 }; public int Red { get; set; } public int Green { get; set; } public int Blue { get; set; } } So hätte man die Farben Schwarz und Weiß als statische readonly Variablen deklariert, die sich per Laufzeit nicht ändern und man kann per RGBColor.Black bzw. RGBColor.White darauf zugreifen. Als zweites Beispiel würde mir die Verwendung von Dependency Injection einfallen. Beispiel: public ClassA { private readonly IDependency dependency; public ClassA(IDependency dependency) { if(dependency == null) throw new ArgumentException(); this.dependency = dependency; } public int DoSomething() { return this.dependency.DoSomething(); } } Ist jetzt zwar ein sehr blödes Beispiel, aber es verdeutlicht, dass ClassA von etwas abhängig ist, was das Interface IDependency implementiert und um sicher zu geben, dass es intern nicht überschrieben wird, wird es als readonly deklariert. Dies ist aber eigentlich auch nur eine Sicherheitsmaßnahme, die nicht not tut, denn in der Regel weiß ich, wie die Klasse tickt, wenn ich sie ändern sollte. Von außen habe ich ja sowieso kein Zugriff. Man sollte sich also im Klaren sein, was man mit dem readonly-Modifizierer erreichen möchte. Die Matrikelnummer sollte zwar nicht änderbar sein, ja aber wir kennen die Domäne nicht, wo diese Klasse verwendet wird und ggf. ist die readonly-Einschränkung zu viel für den Verbraucher, sodass diese Klasse für ihn unbrauchbar wird. Siehe die Deserialisierung oder es kann ja durchaus möglich sein, dass man die Matrikelnummer mal doch ändern möchte und dann müsste man einen hohen Aufwand betreiben um so etwas realisieren zu können, wenn man nicht in der Lage ist, die Klasse ändern zu dürfen, weil sie vielleicht in einer Drittbibliothek steckt.

Die Frage, die ich mir hier stelle, wer will mit wem Daten austauschen? Ihr mit den Kunden oder soll der Austausch nur intern stattfinden? Wenn sie nur intern stattfinden soll und ihr schon eine Windows-Infrastruktur habt, warum dann nicht über eine Dateifreigabe? Wenn die Mitarbeiter auch von Außen darauf zugreifen wollen, dann richtet man ein VPN ein, der dann den Zugriff aufs Intranet ermöglicht. Das hat den Vorteil, dass man Dateifreigaben als Netzlaufwerk einrichten kann. Das ganze lässt sich dann über Active Directory steuern. Wenn ihr mit Kunden Daten austauschen wollt, dann richte ein Filehosting ein. Da wir ebenfalls eine Windows-Infrastruktur verwenden, bot es sich bei uns an, Sharepoint zu verwenden und hier kann man auch HTTPS als Protokoll verwenden. FTP ist eine sehr schlechte Lösung. Vor allem, wenn man Daten mit Kunden austauschen möchten. Viele Kunden sitzen hinter einer Firewall oder hinter einem Proxy und haben keine Möglichkeit vom Firmennetzwerk aus, mit einem FTP-Server außerhalb kommunizieren zu können und für interne Zwecke ist FTP einfach zu nervig. Man muss erstmal den FTP-Client starten und sich dann noch am Server anmelden. Geschweige denn, dass man evtl. noch die Leute dafür Schulen muss. Bei Dateifreigaben kann der Administrator schon die Netzlaufwerke für die Benutzer vorkonfigurieren und sie erscheinen dann beim nächsten Anmelden. Eine Schulung ist somit nicht notwendig. Ein Netzlaufwerk funktioniert dann so wie ein übliches Speichermedium. Also würde es eher so aussehen, dass dein Projekt eher das Einrichten und Administrieren einer Windows-Domäne ist. Mitsamt VPN als Zugriff von Außerhalb und Filehosting für die Kunden.

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.