Структура проекта Qt - нужен совет - PullRequest
7 голосов
/ 29 марта 2011

В настоящее время я работаю над проектом, основанным на Qt4 / QtCreator. Я хотел бы попросить у вас совета о том, как организовать мою заявку.

  • Есть 3 отдельных инструмента, каждый из которых имеет свой вид. Все представления интегрированы в главное окно как закрываемые вкладки. Я подготовил 3 представления: Tool1View, Tool2View, Tool3View

  • Предполагается, что каждый инструмент выполняет некоторую задачу, вызванную действиями пользователя. Но это не связанные с базой данных операции (list / add / modify ...) - по крайней мере, пользователь не собирается добавлять / изменять / перечислять записи в элементах gui.

Я думаю реализовать каждый инструмент в 2 классах:

  • Первый класс ToolXView, реализующий виджет и все задачи, связанные с изменениями графического интерфейса.

  • Второй класс ToolX, реализующий логику приложения. Функции-члены этого класса запускаются классом View. Всякий раз, когда этот класс должен обновлять элементы GUI, он вызывает специализированные функции в классе View. Так что прямые звонки на виджеты отсюда не производятся.

Класс представления и класс логики будут связаны друг с другом для обеспечения двухсторонней связи.

Теперь мне интересно, это хороший путь? Пожалуйста, посоветуйте мне на основании вашего опыта

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

  2. Должен ли я использовать сигналы / слоты для обеспечения связи или просто вызывать функции-члены?

  3. Мне придется хранить некоторые данные в базе данных QtSql. Должен ли я предоставить отдельный класс для доступа к базе данных. Или просто реализовать отдельную функцию-член внутри класса логики?

  4. Как Вы называете Свои занятия? Эта схема хороша, или мне следует ее изменить?

Спасибо за помощь. Я ценю ваши комментарии.

1 Ответ

5 голосов
/ 29 марта 2011

Использование архитектуры mvc замечательно.

1 & 2 - В ссылке выше вы увидите диаграмму UML архитектуры mvc. Что касается этого, я бы подключил сигналы представления к методам контроллера, а затем вызвал метод представления из контроллера.

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

4 - Вы, классные имена, кажется хорошим. Но я бы пошел дальше и назвал занятия:

  • Для просмотра: ClassNameView
  • Для контроллера: ClassNameController
  • Для DataAccessObject: ClassNameDAO
  • Модель: ClassName (и IClassName для интерфейса)

Надеюсь, это поможет

...