@Christoph: Ich glaub du hast einfach zuviel Angst davor. Überwinde dich endlich mal, oder bleib bei VB.
@Jens: Das ist eigentlich recht einfach zu beantworten:
In die Darstellung kommt kein Code der irgendetwas aus der Business-Logik macht. D.h. es werden keine Berechnungen durchgeführt, es werden keine Daten aus der DB ausgelesen. Dann: Zusammenfassen was zusammen gehört und trennen was nicht zusammen gehört. Klingt kompliziert, ist es aber nicht. Nämlich:
Verwenden von unterschiedlichen Namespaces. xy.Data behinhält alles was eben mit Daten zu tun hat. Datenobjekte, Storage-Zugriff etc. Kann bzw. sollte noch weiter unterteilt werden, um die Übersicht erhalten zu können. xy.GUI beinhält einfach GUI Elemente usw. So kann dies recht einfach getrennt werden.
Connection-Infos liegen eigentlich bei mir selten in einer DLL, diese müsste ich ändern und neu verteilen, wenn sich der Connection-String ändert. Wäre eher ungut, daher meist in einer XML-Datei. Die Problematik des DB-Users und DB-Passwortes läßt sich aber umschiffen
Wie gehe ich meine Projekte an? Nun, eigentlich kann ich hier UML sagen
Ich stelle mir jedes Mal aufs Neue die gleichen Fragen:
1. Welches Schichtenmodell ist sinnvoll?
2. In welche groben Teile kann das Projekt unterteilt werden?
3. In welche Klassen etc. kann ich die einzelnen Teile es zerlegen?
4. Wo macht welches Pattern Sinn? Gibt es überhaupt Patterns die mir helfen?
Natürlich gibts noch die eine oder andere Zwischenfrage die entsprechend beantwortet werden muss. Und dann gehts eigentlich los mit der Implementierung (wenn denn dann alles geklärt wurde).
Im Grunde nicht kompliziert, man sollte aber ein gewisse Know-How zum Thema Software-Design/Architektur mitbringen bzw. sich aneignen. Dazu gibt es aber wunderbare Bücher und Artikel.