Модули приложения

[Drake]

Я вижу следующий набор библиотек:
1. Ядро. Основные типы и классы, разделяемые всеми прочими модулями.
2. Работа с хранилищем. Типы и классы, нобходимые для работы с СУБД, и
хранением данных в целом.
3. Скриптовый движок.
4. Графический интерфейс.
5. Отчетная система.

Предложения?

[Vladimir]

В общем и целом согласен. Хотелось бы только немного уточнить.
1. Ядро. Представляет собой набор классов, предназначенных для
хранения в оперативной памяти бухгалтерских объектов (справочников,
документов, отчетов), с которыми работает пользователь в течении
сеанса. Ядро не знает ничего об устройстве остальных модулей программы
и взаимодействует с ними строго через интерфейсные функции.
2. Интерфейс базы данных. Представляет собой класс (классы),
являющийся посредником при обмене данными между ядром и СУБД. Ядро не
знает, с какой именно СУБД оно работает. Наличие такого интерфейса
позволяет заменить СУБД без изменения остального кода.
3. Графический интерфейс. Позволяет отображать содержимое объектов
ядра пользователю и взаимодействовать с ним. Ядро не знает, каким
образом отображаются его объекты на экране.
4. Скриптовый движок. Представляет собой совокупность языка
программирования и функций, с помощью которых пользователь может
программировать обработку объектов ядра в памяти, либо передавать
обработку объектов на сервер.
5. Система отображения объектов ядра на бумаге (печати), либо экспорта
их содержимого в различные форматы обмена данными. Отображать
(экспортировать) можно не только отчеты, но также справочники и
документы.

Вот как-то так.

[Drake]

Да, согласен. И с трактовкой и с зависимостями.
Нужно как-то распределить обязанности. Майлстоуны заполнишь? Я
подготовлю примерное описание и состав библиотек на этой неделе.

[Vladimir]

Хорошо, майлстоуны заполню.

[Vladimir]

Ядро не может совсем ничего не знать о структуре БД - оно генерирует
SQL запросы.

[Drake]

Хм. Для чего? Ядро - библиотека типов и утилитарных классов.
Не логичнее ли оставить все общение с базой на слой базы?
А оно уже передаёт нужные данные ядру в понятных для того терминах.

[Vladimir]

Ядро конечно может не знать конкретных имен таблиц или полей. Оно
может называть их по-своему, а модуль интерфейса БД переведет их в
правильные названия. Но ядро должно знать, что существует план счетов,
справочник типовых операций, таблица документов, сальдо и проводок.
Это очень специфичные таблицы, с ними нужно обращаться определенным
образом. И этим должно заниматься ядро. Поэтому нельзя сказать, что
ядро вообще ничего не знает о БД. Оно знает, что там должны быть такие
таблицы и знает, как с ними обращаться.

[Андрей Дедков]

Вопрос по взаимодействию между модулями. С помощью какого интерфейса
планируется возаимодействие модулей. Например использование TCP/IP
позволит разносить систему на разные машины и разные системы и
получить распределение нагрузки. Далее я не совсем понял какой модуль
с каким взаимодействует. Если я правильно вас понял, то база - драйвер
- ядро - гуи. Поправьте если не правильно понял.

[Vladimir]

Модули - это просто разделенное на библиотеки существующее сейчас
приложение. Разделение на модули планируется для уменьшения внутренних
связей в программе и возможности раздельной работы над различными
частями программы. Все это будет работать на одном клиентском
компьютере, нагрузка на него будет не велика. Ядро - это часть
программы, которая хранит в оперативной памяти и обрабатывает
справочники, документы и отчеты. Для отображения этих объектов
вызываются функции другого модуля - GUI. Для обращения к БД - третьего
модуля, для печати - четвертого. Но повторю - это только планируется
разделить программу на модули. Пока она функционирует как единое
целое, хотя в ней и имеются наметки к разделению на модули.

[trdm]

Мне как-то дали один совет: преждевременная оптимизация зло. Избегай
её.
Я вот смотрю на ваши пересуды по модулям и оно мне тоже отчасти
кажется злом.
Я бы предпочел вообще не оперировать терминами "ядро" и модули. Это
вносит сильно большой слой абстракции.
Для начала надо определиться че пишем.
Если это тупо клиент-сервер без тонкого клиента, то зачем нам
тисипиайпи? ))))
Выпендриться?
Надо отойти от обсуждения "ядер" и определиться что система будет
делать.
Это вам не фрайм, что-бы шинковать и усиленно разводить по модулям. ДА
и к тому же чертовски сложная задача: чем больше запчастей, тем больше
связей прийдется клепать.
тем паче что Qt уже за вас подумала и понастругала достаточно путевый
толстоопый фрайм.
Я бы пока предпочел не слоить систему, а подумать над тем что вообще
требуется.
Представте как она будет работать внутри и каждое действие отдайте
абстрактному компоненту.
ПС. Мои предпочтения - толстый клиент с прямым доступом к БД.
Остальное выкиньте из головы - это работа для сильной команды.

[trdm]

+ ко всему.
Рекомендую прислушаться к моим словам - я инкапсулирую опыт таких
проектов как ананас, qt1L, skm, и еще парочки которые завалились
потому что взяли слишком крутую цель. А выполнить не потянули.
Давайте начнем с простого, а потом будем наращивать.

[Vladimir]

Согласен, что преждевременная оптимизация - это зло.

[Александр Руденко]

Про TCP/IP речи не было, читай внимательнее.

Модули нужно всего и только лишь для четкого структурирования кода. Не исключено, что "модульность" завершится распихиванием исходников по тематическим папкам, и рекомендациями по обращению с зависимостями, а не выделеним полноценных библиотек.

[trdm]

On 19 сен, 11:42, Александр Руденко <drake.l...@gmail.com> wrote:
> Про TCP/IP речи не было, читай внимательнее.
> Модули нужно всего и только лишь для четкого структурирования кода.

ради чего пишете? ради красоты кода?

[Александр Руденко]

Ради результата. Мне удобнее получать результат в окружении, с которым легко работать.

[Vladimir]

Избавился от класса Custom

[Drake]

Эм, я так и не понял зачем)
Он не особо-то и мешался, просто странно выглядел в качестве предка у
Application.
Кстати, я закомитил модульную версию.
Тысяча чертей и одна ведьма, она у меня собиралась, бородой клянусь!

On 5 окт, 16:07, Vladimir <MorozovVladi...@mail.ru> wrote:
> Избавился от класса Custom

[Vladimir]

On 13 окт, 16:24, Drake <drake.l...@gmail.com> wrote:
> Эм, я так и не понял зачем)
> Он не особо-то и мешался, просто странно выглядел в качестве предка у
> Application.

Чем меньше сущностей, тем лучше. Тем более тех, которые смотрятся
странно.

[Drake]

Да, как бы, у Application я и сам исправил, ну а у остальных пусть бы
был.
Ну да ладно.

[Алексей Лежоев]

пишу проектик, который работает с БД и печатает, наткнулся на
подводные камни, кои привели к рефакторингу. Необходимо изначально
подумать о выделении модуля работы с базой, который в свою очередь
единственный, кто знает названия таблиц и полей, остальные получают
данные посредством вызова конкретных методов. Ответ от модуля БД лучше
отдавать в виде сигналов, это упростит обновление данных сразу в
нескольких объектах, завязанных на сигнал, также откроет перспективу
реализации работы приложения не напрямую с БД а через сервер
посредством tcp/ip(сеть то асинхронна и клиентская часть не должна
фризовать в ожидании поступления данных)

получится примерно следующее: форма вызывает метод "дай_список_чего-
то", блокирует элементы от редактирования и выводит сообщение ожидания
данных, получает сигнал, смотрит код ошибки, если все ок, распихивает
полученные данные по полям, удаляет сообщение об ожидании и
разблокирует поля для редактирования. При работе в локальных сетях
пользователь даже не заметит блокировок и ожиданий, зато будет
обезопашен при работе на медленных соединениях или при других
обстоятельствах, вызвавших задержку(может кто-то тем временем DDOSит
сервак с БД)

Также необходимо выделить модуль вывода(печати и экспорта), остальные
должны знать только имя файла шаблона и передавать данные в модуль
посредством вызова методов

[Vladimir]

> Необходимо изначально
> подумать о выделении модуля работы с базой, который в свою очередь
> единственный, кто знает названия таблиц и полей, остальные получают
> данные посредством вызова конкретных методов.

Правильно. Мы будем двигаться в этом же направлении.

> Ответ от модуля БД лучше
> отдавать в виде сигналов, это упростит обновление данных сразу в
> нескольких объектах, завязанных на сигнал

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

> Также необходимо выделить модуль вывода(печати и экспорта), остальные
> должны знать только имя файла шаблона и передавать данные в модуль
> посредством вызова методов

Верно.

[zeal]

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

конечно неправильно, НО сейчас пишу проект учета техники, принятой на
ремонт, и печати сохранных расписок, так вот, существует например
такой параметр как статус... Он есть на основной форме(список техники)
для фильтрации, есть на форме просмотра/редактирования/добавления и
есть на форме управления статусами. При добавлении/изменении статуса
форма управления статусами делает запрос к интерфейсу данных. Как
только интерфейс выполняет поставленную задачу(не важно, напрямую с БД
или через TCP/IP) выдает сигнал о том, что был добавлен/изменен такой-
то статус, и этот статус должен добавиться/измениться аж сразу на 3х
формах иначе пользователю пришлось бы закрывать формы и заново
открывать для применения изменений. Более того, при работе с данными
через сервер TCP/IP в любой момент времени любой другой пользователь
может изменять любые данные, и все остальные пользователи должны
получать эти данные без запроса на их получение, сервер просто
присылает данные на интерфейс данных клиентка, который выдает сигнал и
все формы/объекты, завязанные на этот сигнал, принимают изменения

[Vladimir]

>Более того, при работе с данными
> через сервер TCP/IP в любой момент времени любой другой пользователь
> может изменять любые данные, и все остальные пользователи должны
> получать эти данные без запроса на их получение, сервер просто
> присылает данные на интерфейс данных клиентка, который выдает сигнал и
> все формы/объекты, завязанные на этот сигнал, принимают изменения

Интересно как у вас пользователи получат данные БЕЗ запроса? Как это
сервер просто пришлет данные на интерфейс клиента? Интересно,
поясните. У вас какой сервер используется?

[zeal]

сервер используется самописный, преобразует данные в XML и отправляет подключенным клиентам или одному клиенту, зависит от типа запроса, А сам сервер можно подключать к различным типам БД(которые поддерживает Qt), Таким образом организуется клиент-серверное многопользовательское приложение.

P.S.: с помощью сетевой БД тоже можно организовать многопользовательское приложение, но придется решать проблему своевременного обновления данных клиентами

[Александр Руденко]

Как чудесно было бы жить в мире, где о каждом действии объект мог бы уведомлять нас.

А слушатели - подписываться на уведомления, и поступать сообразно.

Жаль, жаль что нет на свете такой библиотеки и технологии, которая упрощает обработку события об изменении состояния объекта АЖ В ТРЁХ местах сразу, без необходимости закрытия и открытия каких бы то ни было форм.

Остаётся только молиться, поститься и уповать на лучшее. Может быть, когда-нибудь кто-то и создаст подобную прорывную разработку, до тех же пор придётся выдумывать сложности и проблемы на пустом месте.

PS переехал, обосновался, осваиваюсь. Месяца через два готов вернуться в проект, если еще буду нужен.

[Александр Руденко]

2Vladimir

Сообщение товарища zeal следует читать так:"Я не умею пользоваться NOTICE в PostgreSQL и аналогичным функционалом в Оракле.".

Ясное дело, никто там данные без запроса не получает. Просто запрос делается на промежуточном уровне. Ну что ж, каждый извращается по-своему.

[trdm]

On 15 дек, 21:42, Александр Руденко <drake.l...@gmail.com> wrote:
> Как чудесно было бы жить в мире, где о каждом действии объект мог бы
> уведомлять нас.
> А слушатели - подписываться на уведомления, и поступать сообразно.
> Жаль, жаль что нет на свете такой библиотеки и технологии, которая упрощает
> обработку события об изменении состояния объекта АЖ В ТРЁХ местах сразу,
> без необходимости закрытия и открытия каких бы то ни было форм.

Наши предки практиковали магию, ясновидение, яснослышание, шаманство и
т.п.
А потом пришла РПЦ и все стало вне закона.
Уверен, такие сигнальные системы реальность :)
Уверен я потому, что в свое время увлекался йогой, гипнозом,
самовнушением и прочей
лабудой и про присутствие чудес в наше жизни знаю на опыте.
Тока трудно это, пахать нужно - будь здоров + нагрузка на психику
немалая.

> PS переехал, обосновался, осваиваюсь. Месяца через два готов вернуться в
> проект, если еще буду нужен.

Упускать человека с такой квалификацией и опытом? Кто будет вразумлять
тупых 1С-ников
решивших покодить на с++? :)))

[trdm]

On 15 дек, 21:52, Александр Руденко <drake.l...@gmail.com> wrote:
> 2Vladimir
> Сообщение товарища zeal следует читать так:"Я не умею пользоваться NOTICE в
> PostgreSQL и аналогичным функционалом в Оракле.".

тоже не умею.

[Александр Руденко]

Я таки знал, что нужно ставить тэг "ирония".

[Vladimir]

> PS переехал, обосновался, осваиваюсь. Месяца через два готов вернуться в
> проект, если еще буду нужен.

Конечно, очень тебя жду в проекте.

[zeal]

с помощью сигналов-слотов можно обрабатывать событие в сколь угодно местах

[zeal]

четверг, 15 декабря 2011 г. 21:52:19 UTC+4 пользователь Drake написал:

2Vladimir

Сообщение товарища zeal следует читать так:"Я не умею пользоваться NOTICE в PostgreSQL и аналогичным функционалом в Оракле.".

Ясное дело, никто там данные без запроса не получает. Просто запрос делается на промежуточном уровне. Ну что ж, каждый извращается по-своему.

я всего лишь предложил вариант, не стоило хамить 

[Александр Руденко]

Никто и не хамит.

А вам не стоило бы придумывать трудности там, где их нет)

[zeal]

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

[Александр Руденко]

20 декабря 2011 г. 10:15 пользователь zeal <lez...@gmail.com> написал:

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

Объектная модель Smalltalk. Принципы обмена сообщениями.

Паттерны проектирования. Domain object.

Паттерны проектирования. Объектные преобразователи.

Паттерны проектирования. Observer.

Если данные определённого типа выделяются в объект, который умеет отправлять сообщения, а в системе предусмотрен контроллер, своевременно обновляющий данный объект, то проблема обновления клиентов объекта данных сводится к подписке на сообщение и обработке данного особщения.

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

Есть QObject.

Есть сигнал-слот.

Есть СУБД, которые умеют уведомлять клиентов о своём состоянии.

Задача решается написанием монитора, который следит за СУБД и обновляет объекты данных.

Что-то подсказывает мне, что подобное решение проще.

Особо отмечу, что оно не лучше, не хуже - оно лишь проще, поскольку использует готовые подходы.

Что до восхитительной возможности посылать клиенту данные из любых источников - выгода эта для меня несколько эфемерна. СУБД умеет преобразовывать внешние данные в нужный формат. Поддержка различных СУБД? Ну может быть. Если пишете коробочный софт на продажу - это хороший тон. Если же внутренняя разработка - гораздо проще и удобнее завязаться на конкретную СУБД с её особенностями.

Но всё это, повторюсь, всего лишь моё мнение и моё представление о порядке разработки систем. А мнения - они у всех разные. Выделенный сервер приложения тоже имеет право на жизнь, у него есть свои достоинства:)

[zeal]

это интересно, благодарю