Организация структуры приложения

1 Авг
2012

Данная статья очень короткая и написана ради моего интереса. Как правильнее делать?

Введение


Я молодой специалист. Месяц назад закончил обучение. Год назад устроился на работу программистом Qt/C++. Одновременно со мной на работу взяли ещё одного парня постарше, с опытом работы.
Компания разрабатывает программный комплекс, который работает с базой данных. После нашего прихода на нас повесили начало разработки нового проекта. Оба проекта используют карты местности. О предыдущем и будущем проекте и пойдет речь. Точнее об архитектуре данных проектов, т.к. архитектора у нас нету и всё приходится придумывать самим.

Проект №1


Проект разрабатывался до нас. Мы (я и ещё один разработчик) его только дописывали, исправляли баги, придумывали велосипеды и лепили костыли. Архитектура такова: есть n-ое количество виджетов, которые не взаимодействуют друг с другом. Виджеты работают с базой данных, вычитывают и записывают данные. Есть объект (singleton), который создает подключение к БД. Данное подключение виджеты в дальнейшем и используют для работы. Различные виджеты пишут разные разработчики, тоесть в каждом из них свои селекты (SELECT), апдейты (UPDATE) и делиты (DELETE) и ещё куча разной фигни. Существует большое количество виджетов, которым для работы необходимы одинаковые данные. Но каждый из них читает эти данные из базы отдельно. Некоторым виджетам необходим значительный объем данных и они вычитываются несколько минут (хорошо хоть не в потоке GUI) и только потом все вместе отображаются.
Моё мнение — это не есть good.

Проект №2


Проект начали разрабатывать мы (я с другом, им стал этот же разработчик). Конкретной задачи не было, всё было размыто. А мы хотели сделать всё динамично, локанично и гибко (даже слова подобрать не могу). Т.к. мы не очень крутые прогеры, то переписывали мы всё несколько раз (благо никаких дедлайнов и наездов не было). Хотелось чтобы была одна основная модель данных, которая вычитывает и хранит основные данные, необходимые почти каждому виджету (основных всегда работающих виджетов несколько, необходимые им данные должны быть в модели всегда). А так же модель должна вычитать данные для остальных виджетов по мере необходимости.

Что получилось


Ситуация №1

Проект №1. Карта постоянно открыта, на ней отображаются некоторые наши элементы. Пользователь открывает виджет, редаетирует свойства (пускай положение) некоторого объекта, нажимает кнопку сохранить. Виджет записывает данные в базу, база присылает сигнал (notification), виджет карты удаляет все объекты с карты (их может быть много, несколько сотен, например), заново вычитывает всю нужную информацию из базы данных и создает новые объекты.
Ситуация №2

Проект №1. Приложение запущено на двух машинах. Один пользователь изменил положение (или любое другое свойство) объекта, на другой машине на карте изменения отобразились, а в открытом виджете нет.
Ситуация №3

Проект №1. Открыта карти и виджет. На карте мышью изменяется положение объекта, сохраняется в базу, а виджет то об этом не знает и показывает старые данные.
Ситуация №4

Проект №2. Все вышеописанные недочеты убраны. Обращений к базе намного меньше.

Итог


Нам очень долго пришлось отстаивать свою точку зрения, т.к. в отделе есть люди поопытнее. Против нас шли доводы, что запрос на сохранение в базу может не пройти и тогда на разных машинах будет разная информация. Это было всё сделано и продемонстрировано (если запрос не прошел, то значения в модели не изменяются, соответственно и в виджеты приходят соответствующие сигналы или ошибки).
Хотелось бы узнать мнение различных людей, т.к. я пока ещё начинающий программист и очень многого не знаю.
По материалам Хабрахабр.



загрузка...

Комментарии:

Наверх