Architektur für WinForms-Anwendungen?

Question

Ich habe vor ein paar Wochen ein WinForms-Projekt gestartet und da ich nicht wirklich wusste, welche Funktionen ich haben wollte, habe ich sie einfach hinzugefügt. Dies verursachte nun eine schreckliche Verwirrung, in der meine MainForm eine große Schlammkugel ist und wo zum Beispiel einige wichtige Zustandsänderungen durch UI-Elemente ausgelöst werden, bis ich das OnChange-Ereignis eines Controls aufrufen muss, um einen Zustand in der Datenbank zu ändern .

Kurz gesagt: Ich habe gerade ein neues Projekt gestartet, bei dem ich einen besseren Ansatz verfolgen möchte. Ich weiß nur nicht, welcher der "gute" wäre. In ASP.net MVC fand ich das MVVM-Muster wirklich nützlich, aber auf dem Desktop scheint MVVM nur für WPF, nicht für WinForms gedacht.

Der andere Ansatz ist eine dreistufige Architektur: Ich habe meine Datenbank-Klasse, die derzeit direkt mit der Benutzeroberfläche kommuniziert. Ich erstelle jetzt eine neue statische Klasse ("ApplicationState"), die mit der Datenbank kommuniziert und Ereignisse auslöst, um der Benutzeroberfläche "Hey, Something changed!" Zu sagen. Die Benutzeroberfläche würde den Zustand manipulieren, der dann die Datenbankpersistenz behandelt und erneut Ereignisse auslöst, wenn die Benutzeroberfläche aktualisiert werden muss. Der Punkt hier ist, dass die ApplicationState-Klasse die Benutzeroberfläche nicht direkt ändert, sondern dass die Benutzeroberfläche Ereignisse abonniert. Das sieht wie eine saubere/"MVC-y" Art, es zu tun, aber vielleicht übersehe ich hier etwas?

Im Grunde mein ultimatives Ziel wäre, die Benutzeroberfläche vollständig unabhängig von der Datenbankschicht zu haben, nur um sicherzustellen, dass ich die Geschäftslogik nicht erneut in die Benutzeroberfläche einbinde.

Answer 1

Werfen Sie nicht das Handtuch auf MVVM - es ist auch für WinForms gültig. Wenn Sie Datenbindung verwenden, müssen Sie im Grunde eine Entscheidung darüber treffen, an was Ihre Objekte gebunden werden. Oft möchten Sie insbesondere für komplexere UI nicht direkt an Ihre Domänenobjekte binden, sondern spezielle Klassen (manchmal Wrapper) erstellen, an die Ihre UI binden kann, die alles bereitstellen, was die Ansicht benötigt (die Essenz von MVVM) und die Technik funktioniert genauso gut mit Winforms.

Eine gute Serie auf WinForms Model-View-Presenter Ansatz kann bei

The Build Your Own CAB Series Table of Contents

Answer 2

Was würde ich immer für (zunächst) eine geschichtete Anwendung haben

• Presentation Layer (JUST UI und Databinding-Logik)
• Interface Layer zur Business Layer (Definition der Verträge für die Seite BL)
• Business Layer-Implementierung (die eigentliche Logik, Datenvalidierung etc ...)
• Interface Layer auf die Data Access Layer (Definition der Verträge für den Zugriff auf die DAL)
• Datenzugriffsschicht Implementierung

Dies organisiert Ihre Anwendung sehr gut. Dann würde ich nach einem MVC-freundlichen Ansatz suchen. Ich habe nicht so viel mit WinForms entwickelt, mehr mit Asp.net und einigen Java Desktop Clients (wo ich MVC verwendet habe). WinForms arbeitet mehr mit dem .Net-Databinding-Ansatz (DataSource, DataMember, ...). Sie sollten diesen Ansatz wählen, anstatt etwas anderes zu erzwingen. Ich fand, dass es nicht so gut passt.

Was immer nützlich ist, ist unsere UI-Logik in verschiedene Steuerelemente (wie UserControls in Asp.net) zu legen. Dies erleichtert die Wiederverwendung.

Answer 3

Beginnen Sie einfach mit Komponententests für alles, was Ihnen einfällt. Da einige Teile aufgrund der engen Kopplung mit den WinForms schwierig zu testen sind, trennen Sie sie voneinander. Reinigen. Waschen. Wiederholen.

Answer 4

Unsere Faustregel zu finden ist für die meisten Webseiten infolge die staatenlosen Natur des Webs zu MVC lehnen. Wenn Sie nicht versuchen, ein sehr reichhaltiges Web-Erlebnis zu bieten und Silverlight einzubauen, sollten Sie MVVM verwenden. XAML geht Hand in Hand mit MVVM und kann auch Ihre Smart-Client-Wahl sein (oder ein nettes MVCP-Muster).

Wahre MVC ist fast unmöglich unter allen anderen Umständen aufrecht zu erhalten, da die Controller alle Eingaben verarbeiten müssen. Die meisten Nicht-Web-Architektur verfügt über Steuerelemente, die dies für Sie bereitstellen. Tatsächlich sagen die meisten, dass ASP.NET MVC sowieso eine hybride MVC ist, aber es ist sehr gut in meiner Erfahrung.

Answer 5

NDepend Dokumentation enthält einige ziemlich coole und erweiterte Online-Blog-Beiträge, Artikel und Whitebooks über Architektur von .NET-Code.

Advices on partitioning code through .NET assemblies

Control Components Dependencies to gain Clean Architecture

Re-factoring, Re-Structuring and the cost of Levelizing

Evolutionary Design and Acyclic componentization

Layering, the Level metric and the Discourse of Method

Fighting Fabricated Complexity

Auch wenn Sie ständig überprüfen möchten, dass Ihre UI-Code aus Ihrer Datenbank-Code unabhängig ist, können Sie einfach einige Code Query Language Regeln schreiben, die bei der Entwicklungszeit in Visual Studio überprüft werden:

Keep your code structure clean

Answer 6

Nido framework ist gut. Es ist jedoch nur für Ihre Back-End-Architektur. Es gibt Ihnen ein solides, flexibles und einfacheres Backend mit t4template. Es zeigt sich, dass es ein sehr gutes architektonisches Muster hat. Außerdem kann es nicht nur mit WinForm stecken, aber mit einem anderen (MVC ASP.NET etc) Front-End zu ..

Dann wieder RocketFramework ist auch gut

Link1: http://rocketframework.codeplex.com Link2: http://nidoframework.codeplex.com