Ideas for structure of .net GUI app

Question

Hey all-

I'm looking for a strategy on how to structure a VB.net GUI app. I have a application that is basically an interface to a database. It is comprised of a TabControl with 6 tabs, each tab has a few custom controls and performs a business operation on the database.

Tab Functions:

1. Parse an XLS into SQL inserts and commit to db

2. Generate an XLS from db query results

3. Generate an XLS from db query results

4. Quick access data lookup from the db (write to log box)

5. Manual database modification via GUI form (insert / update statement execution)

6. DB connection settings

Common Code Functions:

1. Connecting/disconnecting to/from the DB

2. Executing non-queries

3. Executing queries

4. Iterating over query results

5. Writing to an XLS

6. Common subqueries (DB provider doesn't allow views)

Currently I've got most all of the operations built into event handler functions on the GUI thread. I'd like to move to a more object-oriented structure for code reusability and easier multi-threading.

I'm struggling with a few design things:

1. What objects / classes makes sense?

2. Are there industry-standard best practices or design patterns around separating GUI and backend functionality? Any particularly good articles I should read?

3. Is BackgroundWorker the best way to execute the backend functions?

Thanks-

Jonathan

Answer 1

1. ...is probably too big a question to be readily answered; sorry. But you can make a reasonable first pass by the traditional "looking for nouns" technique.

2. For Windows Forms, check out Model-View-Controller or Model-View-Presenter. (If you use WPF or Silverlight on a future project, you'll want to check out an alternative pattern called Model-View-ViewModel, but that doesn't work too well with WinForms.)

3. Yes, BackgroundWorker is a good bet for WinForms background tasks because it provides a convenient way to deliver progress and completion notifications. It does have some limitations, but explicit threading via Thread or ThreadPool would probably be superfluous here, and would just lead to extra code for GUI feedback. So go with BackgroundWorker at least as a starting point and consider explicit threading only if it starts to cause you pain.