Design Patterns for C# Windows Forms

Question

I'm writing a flashcard program and am running into an issue I always seem to face when writing this sort of Forms program.

I'll describe the program then the issue.

In this program, one main form controls almost all of the action. Depending on the user's input and form events, different buttons/controls may become enabled or disabled, text in various boxes may be populated, etc.

For example:

• Some questions might be multiple choice and others require typed input.
• The user inputs their answer and clicks a button -- if they get something wrong, they have the option to override the 'wrong answer' judgement and say it was really a different, correct variant.
• Statistics regarding which questions were answered correctly are kept and used in the decision about what flash cards to show next.

Now the issue.

How do I best create a clean interaction between the "form" code (for example, handling the OK button's onclick command, and enabling or disabling various controls) and the "logic" code (underlying data stores, program logic that does not have immediate implications for display)? If it is all mixed together in the form object code it does not seem right.

Can anyone suggest a design pattern (especially one widely used) that manages this cleanly?

In case it is relevant I am thinking of something like this:

• Object Model:
  • Class MyForm: the form itself.
  • Class FormController:
    • Child class of MyForm.
    • Instantiation requires an object of type MyForm.
    • FormController's job is to put its MyForm object into a particular "state," by enabling/disabling controls, displaying various text, etc.
    • FormController exposes a small set of public functions which deal with semantically high-level request for the form state (such as "DisplayNewQuestion(QuestionData d)")
  • Class Session: Contains all underlying persistent data or objects involving this session, including lists of possible questions, objects that select the next question from the list, etc.
  • Class Driver: Drives both the Session and FormController objects. For example, it would ask the Session object for a new question, and pass it to the FormController object to update the form.

The advantage to something like this is that icky form code and nice logic code are now completely separable. But is it worthwhile? Are there better or more common design patterns for this?

Thanks a ton!

Answer 1

I am always most comfortable with Model View Controller in this situation. The Shade Tree Developer wrote the most informed series I have ever read on the subject, see here

The jist of MVC is

Model contains the data to be displayed

View is your form and only has logic for displaying and informing of user interactions

Controller contains the glue to make it all happen, including the business logic.

The depenencies should be

Model doesnt know about the view or the controller

View knows about the model and knows how to extract data from it to display

Controller knows about the Model and the view, instansiates them both and wires them together.

The model raises an event when it changes, the view captures this event and refreshes its display accordingly.

The view raises an event when a user interaction occurs, the controller captures this event and performs the correct action for the interaction whether that be updating the model or saving or clearing or whatever.

The view should not write to the model itself

You will see a lot of code where the form creates the controller but imo this is wrong. It came about because of people trying to apply this pattern in asp.net webforms where you have no control over the lifecycle, the first thing that always got created was a view so you had no choice but to have this create your controller, however in winforms you are in control, so make it clean, have the controller create the view.

Answer 2

You might want to use the Model-View-Controller (MVC) design pattern, in which the "logic" is your controller and the "view" is your UI. The model is used to access and retrieve data from your data source (a SQL database for instance)

It is worthwhile to separate your logic from your UI, because it makes them more maintainable. For example, if you want to change your UI from a winform to a web page, you don't have to redo all your logic.

Also, it makes up for a really cleaner code. Using design patterns in general helps other programmers understand your code faster as well.