Wie kann man verhindern, dass die Mainform.cs mit immer mehr Code zugemüllt wird?
Hallo,
da ich gerne Windowsapplikationen entwickle, nutze ich (noch) die veraltete "Formsanwendung" als Basis für meine Programme.
Nun ist es so, dass ich (wie sicherlich jeder angehende Entwickler) sauberen, gut wartbaren Code schreiben möchte. Doch in gewisser Weise scheitere ich daran...
Sicher, vieles lagere ich in Klassen aus (ob es dabei Sinnvoll ist, sei mal dahin gestellt). Doch sehr viel spielt sich in der MainForm.cs ab.
Ich weiß ja nicht wie Euer Code aussieht, aber vieles ist bei mir mit Textboxen verknüpft und somit wird es immer mehr und mehr in der Mainform.cs.
Mit viel gesuche kommt man dann an das was man gerade sucht, aber ich denke nicht, dass das Sinn des sauberen programmierens ist.
Also, wie gehe ich es an die Forms.cs nicht mehr so zuzu müllen? Soltle ich mir mal das Buch Clean Code ansehen? Wird man da sicherer im Aufbau eines Programms?
Hallo,
also CleanCode ist defintiv ein gutes Buch um allgemeine Regeln für sauberen Code kennenzulernen. Bei uns in de Firma ist das Pflichtlektüre für neue Kollegen 😃 Der Resharper in Zusammenhang mit Stylecop tut dann den Rest. Wenn ich mir so manche Beispielprojekte aus dem Internet anschaue würde ich mir wünschen das sich mehr Entwickler mit dem Thema beschäftigen würden.
Über deine eigentliche Frage, nämlich der Architektur deines Programmes wirst du da aber meiner Meinung nicht viel finden. Du solltest dir diverse Entwurfsmuster anschauen, welche die Struktur einer Anwendung deutlich verbessern können. Gerade wenn eine Software kontinuierlich wächst und sich dabei die Anforderungen ständig ändern können diese Regeln meiner Meinung nach über den Erfolg oder Mißerfolg einer Software entscheiden. Dabei ist aber natürlich auch immer der Aufwand und Nutzen abzuschätzen. Ein blindes Einsetzen jedes Musters ist natürlich ebenso kontraproduktiv
Model View Presenter ist ein Pattern welches sich für WinForms-Anwendungen eignet.
Ein ORM-Mapper (wie z.B. NHibernate oder EntityFramework) gehört für mich ebenfalls essentiell zu einer sauberen Architektur. Und wenn man sich einen ganz sauberen Programmierstil aneignen möchte dann empfehle ich mal einen Blick auf das Vorgehen bei der testgetriebenen Programmierung.
Um Rekursion zu verstehen, muss man erst mal Rekursion verstehen, muss man erst mal Rekursion verstehen, ....
Ich hoffe mal nicht dass Forms veraltet sind. Sie sind halt eine andere Möglichkeit um ein Programm aufzubauen.
und somit wird es immer mehr und mehr in der Mainform.cs
Es kann ja nur so viel werden wie du Controls im Formular hast. Lagere Controls in andere Forms aus, oder wenigstens in UserControls, dann hast du den Code automatisch in einer anderen Klasse.
Ich weiß man sollte einer datenverarbeitenden Klasse eigentlich keine Kenntnis über die GUI geben. Macht prinzipiell auch Sinn. Aber ich habe mir auch schon Codeteile ausgelagert, die so speziell mit dem zugehörigen Formular verknüpft waren und nirgends anders Sinn bringen, dass die dann eben doch "ihre" Controls direkt selbst kennen. Ein Schritt schöner wäre natürlich, ein Control abzuleiten und dem Funktionalität zu geben, oder eben das UserControl mit eigenen Textboxen.
Saubere Modularisierung ist ist der goldene Mittelweg zwischen unübersichtlichem Zusammenquetschen in einer einzigen Codedatei und dem ebenso unübersichtlichen zerfleddern von Code 😃
Ich danke Euch schon mal für Eure Antworten!
> ist ein Pattern welches sich für WinForms-Anwendungen eignet.
Genau! Vom MVC habe ich auch schon gehört, theoretisch verstehe ich auch was da passiert bzw. passieren soll. Aber in der Praxis weiß ich dann doch wieder nicht wie man das gescheit umsetzt. Die Forms wäre dann ja z.b. das View. Textboxne, Buttons etc. sollen ja auch auf der Forms bleiben, aber viele meiner Steuerungsteile sind dann da auch wieder sehr stark integriert. Und genau die will ich ja dann vom View trennen. Da hapert es aber noch.
Ich hoffe mal nicht dass Forms veraltet sind. Sie sind halt eine andere Möglichkeit um ein Programm aufzubauen.
Weiß nicht, ein Schulungsdozent hatte auf einer C# Schulung mal gesagt, dass Forms von WPF abgelöst wird - früher oder später.
Saubere Modularisierung ist ist der goldene Mittelweg zwischen unübersichtlichem Zusammenquetschen in einer einzigen Codedatei und dem ebenso unübersichtlichen zerfleddern von Code 😃
Richtig, zuviel ausgelagertes macht den Code auch wieder unübersichtlich. Genau wie mir mitunter keine sinnvollen Benamsungen einfallen wollen.
Ein Arbeitskollege sagte z.b. das ich z.b. "GetRowByName" nur nutzen soll, wenn ich wirklich einen returnwert habe, keine void. und Set-Methoden, wenn ich wirklich etwas setze. Mitunter ist das aber gar nicht so einfach, daran zu denken. Bei gewissen Dingen holt man sich ja Werte, auch wenn diese gar nicht zurück gegeben werden (müssen / sollen).
Wie nennt man die dann...
Weiß nicht, ein Schulungsdozent hatte auf einer C# Schulung mal gesagt, dass Forms von WPF abgelöst wird - früher oder später.
Ob Winforms ganz abtreten wage ich zu bezweifeln. MS hat WPF eine Zeit lang sehr gehyped, es ist auch hier im Forum sehr beliebt.
Man braucht es allerdings nicht um sauber zu programmieren. MVP, MVC, etc. funktionieren in Winforms genauso.
Bei gewissen Dingen holt man sich ja Werte, auch wenn diese gar nicht zurück gegeben werden (müssen / sollen).
Dann ist wohl mehr fetch, read, etc. als get geeignet den Vorgang zu beschreiben. Kommt eben darauf an was genau du machst.
Richtig, zuviel ausgelagertes macht den Code auch wieder unübersichtlich. Genau wie mir mitunter keine sinnvollen Benamsungen einfallen wollen.
Um das kommt man allerdings nicht herum wenn man IoC praktizieren will. Da Factories aus der Mode gekommen sind, wird ja heute vermehrt auf DI gesetzt um das zu machen.
As a man thinketh in his heart, so he is.
- Jun Fan
Es gibt nichts Gutes, außer man tut es. - Erich Kästner
Krawutzi-Kaputzi - Kasperl
Allgemeine regeln sind ja, die Logik möglichst unabhängig von der Oberflächen-Technologie auszulagern.
Welche Pattern man für welche Aufgaben oder Oberfläche nutzt, kann man nicht einfach an einem Schema F definieren, sondern ist oft auch einfach Geschmackssache.
Wenn es für alles einen genauen Weg geben würde, dann bräuchte man keine Entwickler mehr.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Weiß nicht, ein Schulungsdozent hatte auf einer C# Schulung mal gesagt, dass Forms von WPF abgelöst wird - früher oder später.
In der Branche braucht man ein hartes Fell. Da wird gefühlte 10 mal pro Tag was neues erfunden, das natürlich "alles bisherige ablösen" wird.
Scherz beiseite, WPF ist sicher keine Eintagsfliege. Aber es wird auch nicht die Lösung aller Probleme sein.
Bei gewissen Dingen holt man sich ja Werte, auch wenn diese gar nicht zurück gegeben werden (müssen / sollen).
Also wenn ich mir einen Wert hole der gar nicht zurückgegeben wird... ähm dann hab ich ihn ja nicht?!
Soll heißen, ich sehe das wie Abt. Man muss seinen Weg zum Teil auch selbst finden und für gut befinden. Zu deutsch: eine gesunde Mischung zwischen Selbstkritik und Zufriedenheit mit dem was man macht 😃
Also wenn ich mir einen Wert hole der gar nicht zurückgegeben wird... ähm dann hab ich ihn ja nicht?!
Nein ich meine man hat einfach keinen Returnwert. In der Methode selber wird aber einiges abgearbeitet. Sie heißt "Getxxxxx" - gibt aber nichts zurück. Also im Grunde ist sie - weil ich nicht auf korrekte Benamsung komme - verkehrt, sie gibt ja halt keinen Wert zurück.
Soll heißen, ich sehe das wie Abt. Man muss seinen Weg zum Teil auch selbst finden und für gut befinden. Zu deutsch: eine gesunde Mischung zwischen Selbstkritik und Zufriedenheit mit dem was man macht 🙂
Ja und ich bin unzufrieden mit meinem Code =) Aber vielleicht kommt das ja noch, ich bin ja erst am Anfang meiner Karriere als Softwareentwickler...
In der Methode selber wird aber einiges abgearbeitet. Sie heißt "Getxxxxx" - gibt aber nichts zurück. Also im Grunde ist sie - weil ich nicht auf korrekte Benamsung komme - verkehrt, sie gibt ja halt keinen Wert zurück.
Simple Regel: Wenn die Methode dir nicht xxxx liefert, dann nenn sie einfach nicht so. Was macht sie denn? Irgendwas berechnet sie, trägt irgendwas wo ein, schaltet etwas frei, prüft was, stellt Daten bereit .......... genau so nennst du sie.
Bitte verliert euch nicht in Details. Das soll bitte auch kein Sammelthread über alle möglichen Programmiertechniken oder gar Methodenbenennungen werden, siehe [Hinweis] Wie poste ich richtig? Punkt 1.2.
Außerdem wurde die Frage der Zukunft von Windows Forms (und WPF) schon ausreichend im Forum diskutiert.
Das wesentliche und eigentliche Thema laut dem Startbeitag habe ich nun auch in den Titel geschrieben und darum sollte sich der Thread nun mehr ausschließlich drehen, also "Wie kann man verhindern, dass die Mainform.cs mit immer mehr Code zugemüllt wird?".
Die kurze Antwort wurde schon gegeben: MVC oder eine Variante davon oder ein anderes GUI-Entwurfsmuster, das den eigenen Geschmack trifft. Ob es noch eine lange Antwort braucht, möchte ich aufgrund der vielen bereits vorhandenen Threads zu MVC und ähnlichen Entwurfsmustern bezweifeln. Die bestehenden Threads - zusammen mit einigen guten Artikeln aus dem Netz - sollten alle Fragen klären, ohne dass wir das erneut durchkauen müssen.