Доступ к базе данных в потоке графического интерфейса, не так ли?

Question

Я работаю над некоторыми примерами MSDN и некоторыми книгами на ADO.Net. Общим для всех является использование в Visual Studio функции времени создания точек / щелчков / перетаскивания для разработки приложений баз данных, привязки наборов данных к элементам управления и т. Д.

И полученный код делает все доступ к БД в потоке GUI, насколько я могу судить. Это звучит как плохая практика, и раздражающее поведение приложения доступа к базе данных, как только запросы начинают занимать время.

Я что-то упустил? Это то, как мы должны разрабатывать приложения баз данных? Я обычно не думаю дважды о размещении сетевого ввода-вывода в отдельном потоке, всегда.

Answer 1

Да, это плохая идея, если вы действительно не заботитесь о зависании графического интерфейса. В некоторых случаях, особенно для «быстрых и грязных» инструментов, это действительно правильный выбор. Если это означает, что вы можете что-то передать пользователю, который все равно будет использовать его в течение пары дней и все равно будет заботиться о том, чтобы выполнить работу в ближайшее время, а не всегда иметь отзывчивый пользовательский интерфейс, то нет смысла тратить время на переключение между потоками. *

Но нет, это не то, как вы должны разрабатывать приложения баз данных, которые должны оставаться отзывчивыми.

Однако я могу понять, почему книги и учебники делают это - по крайней мере, до некоторой степени. Если они пытаются научить вас доступу к базе данных, а не многопоточности, это означает, что большая часть кода будет иметь отношение к предмету, чем если бы все было абсолютно «рабочим кодом». По своему опыту я знаю, что сохранить "обучающий код" настолько чистым, насколько хотелось бы.

Тем не менее, я думаю, что было бы хорошей идеей для таких руководств и книг, чтобы объяснить это сразу, чтобы они не привели к вредным привычкам.

Answer 2

Обратите внимание, что основная проблема этой практики не связана с многопоточностью, а связана с разделением задач. Тесно привязывая доступ к базе данных к пользовательскому интерфейсу, они теряют возможности, доступные при разделении, и требуют изменений БД при изменении пользовательского интерфейса и наоборот.

Будет ли важно находиться в одной ветке или нет, будет зависеть от обстоятельств, платформы и т. Д.

Answer 3

Да, это плохо .

Что если ваш запрос занимает 20 секунд? Прощай, интерфейс.

ИМХО, причина, по которой так много сэмплов построено так, состоит в том, что асинхронные шаблоны в .Net довольно грязные.

Представьте, если ваши образцы выглядят так:

    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 
    }

Сравните это с придуманным синтаксисом (который может быть достигнут с помощью postsharp)

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

Answer 4

Множество примеров MSDN и сама Visual Studio поддерживают антипаттерн «умная форма», где вы перетаскиваете вещи на холст и подключаете небольшой код, и у вас есть что-то работающее. Они стремятся к легкому начальному уровню без большого количества сложностей с этим материалом.

Было бы более оптимальным иметь рабочий поток для выполнения любых интенсивных операций ввода-вывода и поддержания отзывчивости вашего графического интерфейса (если цель не состоит в том, чтобы заставить что-то работать за 10 минут).

Answer 5

Плохо это или нет, полностью зависит от типа приложения. Если запросы имеют характер, что они не занимают много времени, не может быть плохой идеей не допускать сложность потоков в картину. Но как только у вас начнутся трудоемкие запросы, вам, вероятно, захочется, чтобы они были в собственном рабочем потоке.

Answer 6

Во многих случаях вы определенно захотите реализовать разделение между графическим интерфейсом пользователя и кодом доступа к данным.

Однако большинство книг предоставляют информацию о функциях, а не о лучших практиках архитектуры.