Architecture for WinForms applications?

Question

I have started a WinForms project a few weeks ago and as I did not really know what features I wanted, I just added them along the way. This now caused a horrible mess where

Answer 1

What I would always go for (first) is to have a layered application

• Presentation Layer (JUST UI and databinding logic)
• Interface Layer to the Business Layer (defining the contracts for accessing the BL)
• Business Layer implementation (the actual logic, data validation etc...)
• Interface Layer to the Data Access Layer (defining the contracts for accessing the DAL)
• Data Access Layer implementation

This organizes your application extremely well. Then I'd look for some MVC kind approach. I did not develop so much with WinForms, more with Asp.net and some Java Desktop clients (where I used MVC). WinForms works more with the .Net databinding approach (DataSource, DataMember,...). You should go for that approach instead of trying to force something other. I found that it doesn't match that well.

What's always useful is to lay out our UI logic into different controls (like UserControls in Asp.net). This facilitates reuse.

Answer 2

Don't throw in the towel on MVVM - it's valid for WinForms as well. Basically, if you use data-binding, you have to make a decision about what your objects will bind to. Often, especially for more complex UI, you dont want to bind directly to your domain objects, you want to build specialized classes (sometimes wrappers) that your UI can bind to which provide everything the view needs (the essence of MVVM) and the technique works just as well with Winforms.

A good series on WinForms Model-View-Presenter approach can be found at

The Build Your Own CAB Series Table of Contents

Answer 3

Okay,
I found some nice answers above but as per my 4+ years of experience in winform, I can say that you can use dotnet remoting for this purpose. In simple words, you need to create one solution for your business logic and client side works and another solution for connection with the database which you can called as a server. Both solution should contain some common projects and then you can easily works on your application without worry about your database.
I would suggest you to read about dotnet remoting.

Hope, this answer is helpful.

Answer 4

Just start writing unit-tests for everything you can think of. As some pieces will turnout difficult to unit-test because of tight coupling to the WinForms, separate them out. Clean. Wash. Repeat.

Answer 5

Our rule of thumb is to lean towards MVC for most websites due to the stateless nature of the web. Unless you're trying to provide a very rich web experience and bring in silverlight, then you should go with MVVM. XAML goes hand to hand with MVVM and can be your smart client choice as well (or a nice MVCP pattern).

True MVC is almost impossible to uphold in any other circumstance due to the fact that controllers are suppose to handle all input. Most non web architecture has controls that will provide this for you. In fact, most say that ASP.NET MVC is a hybrid MVC anyways but it's very good in my experience.

Answer 6

NDepend documentation comes with some pretty cool and advanced online blog posts, articles and white books concerning architecture of .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

Also, if you want to continuously check that your UI code is independent from your database code, you can write easily some Code Query Language rules that will be checked live at development time in Visual Studio:

Keep your code structure clean