How to structure VB.NET windows forms applications

Question

What is the best way to structure a VB.NET windows forms application so that code can be reused and the app can be extended easily.

I used to create lots of new forms. This lead to lots of repeated code and forms which did similar things.

Now, for forms which do similar jobs, such as view/edit/delete items from a specific db table, I create a form with the required controls, have the form create an instance of a class with params such as a collection of the controls and a string containing the db table name. Then the individual controls call functions of the class.

Advanced forms will inherit and extend this basic form class.

1. Has there already been work done in this area?
2. Are there books / articles available which discuss the options available on this topic?

Answer 1

I had great success with this Passive Screen

In my opinion the big problem of the traditional MVC architecture is that people stuff way too much into the form classes. This increases the amount of manual testing you have to do.

The more automated testing you can do after you compile the more bugs you will catch at your desk. In a complex application side effect from even minor changes occur all too often.

The trick to solving this is making a controller assembly that the form assembly (or EXE) references. Every form has a corresponding class in the assembly. Clicking a button will call ThisForm.ThisButton() which will then fire object lower in your framework. Each form implements a interface so that if the controller class needs additional information from the form it has a interface to retrieve it.

Then for your Unit Testing you simulate an operator performing complex operations by implementing dummy classes to fire events and feed information to the controller classes. The controller classes don't know any different as the dummy classes implement all the expected interfaces.

There is an important exception and that is for trivial dialogs. For dialogs that have a few check boxes I feel this organization is overkill. I use the command pattern a lot. So in the assembly where I define the Command objects I put the SIMPLE dialog associated with that command. How simple a dialog has to be to get this treatment is up to you.

I like to structure my applications as follows.

Utility - This is an assembly that has stuff I use all the time - Math fucntions, file function, etc.

Objects - This has the specific objects I am using for this applications

UIFramework - This defines all form and controller interfaces.

Commands - This has all the Command objects that manipulate my Application Objects.

UI - Objects that implement the Controller interfaces

EXE - Forms that implement the form interface and calls the controller objects.

Answer 2

You may want to check out a Rocky Lhotka's popular CSLA Framework. It provides a very structured way to implement business objects so you can keep the non-UI code out of your forms. Beyond just separating your business logic though, it provides built in n-level undo, validation, security, data binding support, etc.

The one complaint most commonly directed at CSLA is that it makes test driven development difficult, so that may be something to consider as well.

Answer 3

Something that can help a lot is the use of User Controls. With user controls you can reuse the same UI in different forms. Also, you can have many user controls on one form, so if you have a form with a tabcontrol that has 5 tabs, the content of each tab could be a user control, so instead of having hundreds of controls all mixed up in one form, each user control has its own controls and validation logic, and you end up with just six controls in the form: the tabcontrol and the 5 user controls.

This doesn't help in separating UI code from application logic, but it enables you to have small, structured entities instead of forms with thousands of lines of code.