Database access in GUI thread , bad isn't it ?

Question

I'm working through some MSDN examples, and some books on ADO.Net. What they all have in common is using the point/click/drag-drop design time feature in Visual Studio to develop database applications, binding data sets to controls etc.

And the resulting code does all DB access in the GUI thread, as far as I can tell. This sounds like bad practice, and annoying behavior of the application of the database access once queries starts to take time.

Am I missing something ? Is this how we're supposed to develop database applications ? I usually woudn't think twice about placing network IO in a seperate thread, always.

Answer 1

Yes, it's a bad idea unless you really don't care about having the GUI hang. In some cases, particularly for "quick and dirty" tools, that's actually the right choice. If it means you can get something to a user who's just going to use it for a couple of days anyway and cares about getting the job done soon rather than always having a responsive UI, then there's little point wasting time hopping between threads.

But no, it's not how you're meant to develop database applications which are meant to stay responsive.

However, I can understand why books and tutorials do it - at least to some extent. If they're trying to teach you database access rather than threading, it means that a greater proportion of the code is going to be relevant to the subject matter than if everything was absolutely "production code". I know from experience that it's tough to keep "teaching code" as clean as one would like.

However, I think it would be a good idea for such tutorials and books to explain this right up front, so they don't lead to bad habits.

Answer 2

In many cases, you would definitely want to implement separation between the GUI and the data access code.

However, most books are providing information on features, not on architecture best practices.

Answer 3

Whether this is bad or not entirely depends on the type of application. If the queries are of a nature that they do not take a lot of time, it may not be a bad idea to keep threading complexity out of the picture. But as soon as you start to have time consuming queries you will probably want to have them on their own worker thread.

Answer 4

A lot of MSDN examples and Visual Studio itself encourage the "smart form" antipattern where you drag stuff on the canvas and wire up some small code and you have a working something. They are aiming at easy entry-level without a lot of complications with this stuff.

It would be more optimal is to have a worker thread to do anything IO intensive and keep your GUI responsive (unless the goal is to get something working in 10 minutes).

Answer 5

Note that the main problem with this practice has nothing to do with threading, but with separation of concerns. By binding database access so tightly to the UI, they lose the possibilities available by separation, and will require DB changes when the UI changes and vice versa.

Whether it matters to be in the same thread or not will depend on the circumstances, platform, etc.

Answer 6

Yes its bad.

What if your query takes 20 seconds? Goodbye UI.

IMHO, the reason so many samples are built like this is that async patterns in .Net are quite messy.

Imagine if your samples looked like this:

    private void BasicAsyncWithNoProgress() {

        if (Application.Current.Dispatcher.Thread != System.Threading.Thread.CurrentThread) {
            Application.Current.Dispatcher.Invoke((System.Windows.Forms.MethodInvoker) BasicAsyncWithNoProgress, null);
            return;
        }

        // Do Work 
    }

Contrast this to an invented syntax (that could be achieved with postsharp)

[NotOnUIThread]
private void BasicAsyncWithNoProgress() {
        // Do Work 
}