Разделение интерфейса и логики приложения

Question

Arrow18 июля 2018 г. 7:20

Разделение интерфейса и логики приложения

Добрый день!

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

С таблицами, выборками и поиском все ясно, их необходимо с использования QTableModel, QRelationTableModel и т.д. перевести на QSqlquery.

Вопрос в том как быть с полями редактирования данных (QLineEdit, QTextEdit и др.)?

Работа с ними организована при помощи QDataWidgetMapper. Выполнять запрос Sql и потом из него вытягивать результаты и раскидывать по нужным полям (по очереди в цикле) или есть другой вариант.

И как быть с тем, что таблиц много и писать под каждую свой запрос не очень то и хочется (это только для отображения данных в таблице, а еще и редактирование данных / отдельная форма с QLineEdit, QTextEdit и др. под каждую таблицу/ ).

Больше хочется сделать, что-то универсальное, чтобы не пришлось в классах форм писать что-то типа:

MyClass *class = new MyClass();
class.sql("SELECT ... FROM ...");

то-есть описывать сам запрос в классе формы.

Как можно поступить в данной ситуации?

Рекомендуем хостинг TIMEWEB

Стабильный хостинг, на котором располагается социальная сеть EVILEG. Для проектов на Django рекомендуем VDS хостинг.

Подписка на обсуждение2

Подписка на раздел248

Вам это нравится? Поделитесь в социальных сетях!

19 июля 2018 г. 3:38

Добрый день!

Ой зря Вы это затеяли. Модели данных - это как раз и есть логика, а всякие QTableView, QTableWidget - это представление, интерфейс приложения.

В рамках использования Qt, переводить всё на QSqlQuery - это неправильно, человек, который будет после вас поддерживать этот код, как первым делом займется тем, что будет обратно переписывать всё на модели.

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

Arrow → Evgenii Legotckoi
#

19 июля 2018 г. 4:00
(ред.)

Спасибо, а то я чуть не согрешил :).

Фасад для подключения к базе данных написан ( спасибо за статью :) ).

P.S. Вопрос возник из-за просьбы вынести работу с базой данных в отдельный файл / файлы.

Evgenii Legotckoi → Arrow
#

19 июля 2018 г. 4:47
Ответ был помечен как решение.

Проанализируйте, что именно можно вынести в качестве функционала, который не требует представления в виде таблиц или маппинга в диалоги. То и переносите.

Возможно потребуется что-то продублировать, чтобы получать вектор объектов или ещё что-то в этом роде. Но модели и мапперы оставьте, иначе наделаете себе уйму головной боли в будущем.

Arrow → Evgenii Legotckoi
#

19 июля 2018 г. 4:56
(ред.)

Все, что касалось подключения к базе, проверки логина и пароля и еще несколько аспектов работы с ней, вынес еще на начальном этапе.

Написал свой класс для форм (вынес в них общую логику), создал модели для QComboBox и QListView.

Уже остались только стандартные модели и мапперы. Значит больше выносить не чего.

Огромное спасибо еще раз !

Evgenii Legotckoi → Arrow
#

19 июля 2018 г. 4:57

Получается, что так. Успехов.

Разделение интерфейса и логики приложения

Рекомендуем хостинг TIMEWEB

Комментарии