Refactoring Windows Forms Application

Question

I am developing a windows forms application. It was basically evovled with a mix of BDUP and prototyping.

I have about 1500 lines of code (excluding IDE generated partial class... 1465 to be exact) in the form and the form has 6 tabs (9 subtabs). Does not have more than 10 controls in each form so multiple form solution would be an overkill.

I have a set of entity classes that when serialized give me an XML representation that I store in an XML file. I've encapsulated this with a Repository pattern so I could move the storage to a database in future. The form uses the entity classes (for save/edit) and the Repo factory (add, retrieve and save).

Now, my problem is that much of the 1500 lines of code deals with interaction between UI elements (making a choice in a Combo disables some elements, or displays different items in a grid, handle tab transitions (next/back buttons), loading menus (each distinct item in the xml file repository becomes a menu item), new/edit mode etc (I've three distinct sets of new/edit on the same form).

1. What would be best approach here to move the element interaction out? Let's say, I may decide to make it web-based UI in future.
2. More importantly what are the composite refactorings I can apply?
3. What patterns I should refactor to / towards?

Thanks for helping out.

Note: I'm reading Refactoring to Patterns... Specifically I wanted to have a "howto"/tips on Refactoring to MVC...

Answer 1

Hello

You should look into the Model-View-Controller (MVC) design pattern to abstract your business logic from your display logic.

There is also another flavor of the same thing called the Model View Presenter.

Both of these are extensively documented on the net.

Regards, Joon

Answer 2

Martin Fowler describes different UI architectural patterns in this article. It's fairly long, but well worth reading. You will then be able to determine which patterns and architectural models fit your scenario the best.

At the end of the "Model View Controller" section of that article, Fowler mentions these items, which seem applicable for you:

• Make a strong separation between presentation (view & controller) and domain (model) - Separated Presentation.
• Divide GUI widgets into a controller (for reacting to user stimulus) and view (for displaying the state of the model). Controller and view should (mostly) not communicate directly but through the model.
• Have views (and controllers) observe the model to allow multiple widgets to update without needed to communicate directly - Observer Synchronization.

See the article and its links for more information. Good luck!