Entwickler-Ecke :: Thema anzeigen - Grundlegendes zum Softwaredesign in C#

jg72 - Fr 03.02.12 13:19
Titel: Grundlegendes zum Softwaredesign in C#

Hallo Zusammen,

als langjähriger Entwickler in anderen Sprachen befasse ich mich nun seit einiger Zeit schon mit C# und dem .Net-Framework, insbesondere der Windows Forms-Entwicklung

Da hier nun die Projekte mehr und umfangreicher werden bin ich nun an einem Punkt angelangt, wo ich einfach nicht mehr richtig entscheiden kann, wie ich überhaupt programmieren soll. Insbesondere habe ich defizite zu den folgenden Themen:

Ordnen des Quellcodes
Navigation im Quelltext / wiederfinden von Methoden usw.
komplexes Databinding (DataSets vs. eigene Klassen vs. ?)
Design von Mehrschichtenanwendungen
Generell gutes Design in C#

Es hört sich sicherlich schlimmer an, als es wirklich ist. ;)

Was mir zuletzt die Motivation genommen hat: Ich habe mich für ein umfangreicheres Testprojekt auf die Verwendung von DataSets festgelegt. Die Daten wurden dann per DataBinding an Steuerelemente gebunden.

Es hat auch alles grundsätzlich funktioniert, doch an manchen Stellen bricht dann das ganze Gerüst in sich zusammen. Es passiert halt oft nicht das (vor allem dann) wenn man es erwartet und das Binden an DGVs ist bei verschiedenen DataTables unmöglich.

Bevor ich jetzt aber zu stark in Selbstmitleid zerfließe: könnt ihr mir gute (weiterführende) Literatur (online oder toter Baum) empfehlen? Alles was ich bisher an Büchern gefunden habe, ist mir zu sehr für Anfänger geschrieben oder viel zu losgelöst von der konkreten Umsetzung in C#.

Vielen Dank schonmal für alle Hinweise,
jg72

mats74 - Fr 03.02.12 15:03

Hallo jg72

jg72 hat folgendes geschrieben :

Was mir zuletzt die Motivation genommen hat: Ich habe mich für ein umfangreicheres Testprojekt auf die Verwendung von DataSets festgelegt. Die Daten wurden dann per DataBinding an Steuerelemente gebunden.

Es hat auch alles grundsätzlich funktioniert, doch an manchen Stellen bricht dann das ganze Gerüst in sich zusammen. Es passiert halt oft nicht das (vor allem dann) wenn man es erwartet und das Binden an DGVs ist bei verschiedenen DataTables unmöglich.

An diesem Punkt war ich vor einem halben Jahr auch angekommen. Ich hatte die DataBindings unter den verschiedenen Tabellen durch eigene Methoden ersetzt. ich habe die Datenverarbeitungsprozesse in die kleinst möglichen Methoden aufgegliedert und somit den Datenfluss unter den Tabellen aus eigener Hand ausführen lassen. In den einzelnen Methoden habe ich dann auch Überwachungs-Exeptions gesetzt, die mir beim "Krachen" der Datenverarbeitung klare Hinweise ausgeben, wo der Fehler entstanden ist. Damit ist natürlich viel Arbeit verbunden, der grosse Vorteil dabei ist, Du hast die absolute Kontrolle über den Datenfluss und kannst ihn jederzeit beeinflussen.

Der Datenfluss bei einigen Projekten sieht bei mir so aus:
- SQL-Server (dauerhaft gespeicherte Daten)
- DataSet (Temporäre Daten / Systemdaten des Programms)
- DataGridView's (Ein- Ausgabe am Bildschrim des User's (Infoschicht))
- Eingabesteuerelemente z.B. Textbox's (Usereingaben)

Ich denke, mit DataBinding-Methoden hätte ich die komplexität meiner jetztigen Datenstruktur nicht hingekriegt. Wie Du schon sagtest, es kracht und du hast keine Ahnung warum. Ob dies der richtige Weg ist, habe ich aber keine Ahnung. Bis jetzt ist jedenfalls mein System sehr stabil.

Für Fachliteratur oder sonstige Hinweise wäre ich natürlich auch glücklich. Ich habe leider bis jetzt keine grösseren Projektstrukturen einsehen können. Vielleicht kennt sich da noch jemand anderes besser aus. Ansonsten nicht verzagen und weitermachen :wink: ...

Ralf Jansen - Fr 03.02.12 17:26

Hört sich eigentlich nach Problemen an die sich mit Erfahrung lösen und weniger mit Büchern ;)

Zum Thema Design würde ich die Framework Design Guidelines empfehlen. Die gibts zwar auch im Netz aber die Buchversion [http://www.amazon.de/Framework-Design-Guidelines-Conventions-Development/dp/0321545613] ist von vielen intelligenten Leuten der Szene kommentiert. Insbesondere dann wenn es um kontroverse Guidelines geht und die Meinungen in den Kommentaren auseinandergehen gibt es viel zu lernen was einem in der Version auf den MSDN Webseiten abgeht. Wenn du keine Angst vor teilweise sehr abgehobenen Designmethoden hast dann kann ich auch die Pattern&Practices Group bei Microsoft empfehlen. Deren Architecture Guidelines [http://www.amazon.de/Microsoft%C2%AE-Application-Architecture-Patterns-Practices/dp/073562710X/ref=sr_1_28?ie=UTF8&qid=1328282092&sr=8-28] findest du ebenfalls auch in der Msdn [http://msdn.microsoft.com/en-us/practices/hh124092] wie vieles andere interessante.

mats74 - Fr 03.02.12 17:55

Ralf Jansen hat folgendes geschrieben :

... Hört sich eigentlich nach Problemen an die sich mit Erfahrung lösen und weniger mit Büchern...

Woher stehlen wenn nicht schon geklaut? Erfahrung heisst im eigentlichen Sinne "schon mal gemacht zu haben", was ,wie bei allen ersten Mals, schwierig sein wird ... :mrgreen:

Danke euch beiden für eure Buchvorschläge. Da wird uns die Nachtlekture ja nicht so schnell ausgehen.
Ich werde es mir jedenfalls mal zu Gemüte führen.

jg72 - Sa 04.02.12 00:11

Ralf Jansen hat folgendes geschrieben :

Im Scheitern auf dem Weg zur Lösung liegt das Verstehen.

Ich bin schon auf vielen Wegen gescheitert und habe meist auch was dabei gelernt 8)

Schön wäre es aber doch, wenn es eine kleine Karte geben würde. Insbesondere bin ich nicht sicher, ob z.B. Databinding nicht eine Sackgasse ist und da wäre es schon ganz nett, wenn man auf die Erfahrung anderer Entwickler zurückgreifen könnte.

Ralf Jansen - Sa 04.02.12 01:16

Zitat:

Insbesondere bin ich nicht sicher, ob z.B. Databinding nicht eine Sackgasse ist und da wäre es schon ganz nett, wenn man auf die Erfahrung anderer Entwickler zurückgreifen könnte.

Meine Erfahrung ist das Databinding funktioniert. Auch wenn du von Problemen mit Grids berichtest ist das genau das Beispiel wo ich auf Databinding nicht verzichten möchte.
Ein Grid ohne Databinding mit allen was dazu gehört (z.b. automatische Synchronisierung in beide Richtungen) zum Laufen zu bringen ist eine Selbstgeißelung aber kein programmieren. Wenn du an dieser Stelle Probleme hast würde ich die eher auf das Benutzen von Dataset/Datatable schieben als auf Databinding als solches. Mit einem selbst geschriebenen oder generierten Model hat man einfach mehr Kontrolle. Und bei der Benutzung von Datasets neigt man dazu Dinge zu vermischen die man nicht vermischen sollte.

Databinding als Komplettlösung sehe ich aber kritisch. Binding ist konzeptionell ja etwas schwach typisiertes (man legt über ein String Propertynamen eines Objektes fest) wenn du also etwas am Modell änderst wird es keinen Compilerfehler geben wenn das Binding nicht mehr zum Modell passt (Jemand mit mehr WPF Erfahrung soll mir widersprechen wenn es da anders aussieht). Na klar kann man UI-Test schreiben die das bemerken. Aber mal ehrlich wer macht sowas? Ich bin ja schon froh wenn in den Teams an denen ich beteiligt bin nicht triviale Unittests für zumindest die wichtigsten Codeteilen geschrieben werden :( Als Einzeltäter mag Databinding beherrschbar sein in einem Team wird es schnell zum Problem.

Kha - Sa 04.02.12 01:49

Nicht gerade aus der realen Wirtschaft gegriffen, aber über ein Semesterprojekt mit 6 Mann, mittlerweile etwa 6k LOC und WPF+MVVM als Basis kann ich berichten, dass Data Binding uns überhaupt keine Probleme bereitet - abgesehen von der Einarbeitungszeit ;) . Änderungen an der öffentlichen Schnittstelle sind selten (dem Wasserfallmodell sei Dank, uff...), vielleicht gerade deswegen wurde bis jetzt immer daran gedacht, auch die View zu aktualisieren.

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!