|
Сообщение создано: 23. 06. 2009 [10:35]
|
|
Nerobarain
Мансуров Асхат
Создатель темы
Зарегистрирован(а) с: 23.06.2009
Сообщения: 3
|
Работаю с Qt4 совсем немного, но заметил, что там есть собственная поддержка различных БД. Т.е. используя один и тот же класс можно работать с различными БД, только меняя идентификатор драйвера. Вот и хотел узнать, есть ли возможность использовать библиотеки Qt, или придётся много работы переделать?
|
|
Сообщение создано: 23. 06. 2009 [10:57]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
Nerobarain wrote:
Работаю с Qt4 совсем немного, но заметил, что там есть собственная поддержка различных БД. Т.е. используя один и тот же класс можно работать с различными БД, только меняя идентификатор драйвера. Вот и хотел узнать, есть ли возможность использовать библиотеки Qt, или придётся много работы переделать?
OpenSCADA это GUI-toolkits независимая система, что между прочем позволяет её исполняться в ограниченных окружениях без GUI вообще, например в роли сервера или среды исполнения PLC на носителях порядка 10-30Мб. Или-же прикрутить GUI скажем на GTK+.
Для БД в OpenSCADA есть своя модульная подсистема, которая уже содержит модули почти всех БД поддерживаемых QT.
Кроме того, создание модуля поддержки БД к подсистеме БД OpenSCADA вовсе не сложно. В общем реализуется только SQL-интерфейс через специфичный для БД API, а это кода строк на 50, а всё остальное стандартно для модулей БД.
Модуль можно реализовать и на API БД QT, но в таком случае это потянет зависимость на QT. И это не сложно, но было не нужно.
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 24. 06. 2009 [05:34]
|
|
Nerobarain
Мансуров Асхат
Создатель темы
Зарегистрирован(а) с: 23.06.2009
Сообщения: 3
|
Всё же немного не понятно использование такого большого количества разных библиотек. Qt позиционируется как полноценный кросс-платформенный фреймворк. И его GUI часть только поверхность, а такие классы, как 'QSqlDatabase','QSqlQuery' и 'QLocalSocket' не требующие визуальную часть, с лёгкостью обходятся без него. Это ни в коем случае не рекомендация и не совет. Мне в первую очередь интересно ваше мнение как разработчика: "Почему не стоит этого делать?!".
|
|
Сообщение создано: 24. 06. 2009 [09:51]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
Nerobarain wrote:
Всё же немного не понятно использование такого большого количества разных библиотек. Qt позиционируется как полноценный кросс-платформенный фреймворк. И его GUI часть только поверхность, а такие классы, как 'QSqlDatabase','QSqlQuery' и 'QLocalSocket' не требующие визуальную часть, с лёгкостью обходятся без него. Это ни в коем случае не рекомендация и не совет. Мне в первую очередь интересно ваше мнение как разработчика: "Почему не стоит этого делать?!".
Потому что существует часть системы, большая, для которой функций любого фреймворка не достаточно.
Например, такая часть системы как "Сбор данных", про особенности и интерфейсы которой QT ничего не знает. А для отдельных частей (модулей) "Сбора данных" существуют библиотеки API, чаще всего, а порой и только, доступные на C. Иногда же, в случае с коммерческими протоколами, нет и этого и нужно мутить самостоятельно. Эта же проблема характерна и для подсистемы "Транспорты" и "Транспортные протокола". На чём эти особенности реализовывать? Конечно-же на наиболее развитом и распространённом стандарте API системного уровня - POSIX и STL, которые кстати в полной мере используется и самой QT.
Более того приведенные вами классы БД в полной мере не решают доступ к БД. Это всего лишь достаточно тонкие прослойки над API отдельных БД. А существует реальное различие в диалектах SQL различных БД. Начиная от особенностей квотирования и заканчивая степенью реализации отдельных запросов и команд, как яркий пример это ALTER. Именно в подсистеме БД OpenSCADA эти особенности и решаются предоставляя для остальных подсистем унифицированный доступ к БД.
Если глянуть и на остальные подсистемы то окажется, что для обеспечения гибкости привязка к одному фреймворку противопоказана.
Кроме технических проблем есть и проблема эксплуатационная. Как я ранее говорил OpenSCADA это далеко не чистая SCADA-система, а ещё и ряд смежных решений. Например, среда исполнения PLC. А в ряде таких решений любая зависимость, особенно такая тяжёлая как QT, может быть непреодалимым препятствием. В случае же с существующей архитектурой я модули с тяжелыми зависимостями и не нужными функциями могу просто исключить. Например, могу сконфигуировать среду исполнения или сервер без модулей на QT, в режиме демона, но полноценно доступные для конфигурации как через WEB-интерфейс, так и с удалённой станции администратора, через тот же QT-интерфейс. И даже могу запустить сервер визуализации, с непосредственной визуализацией удалённо хоть в QT, хоть через WEB.
Мало того, есть ещё фактор привязанности к той или иной технологии или адаптируемости. Может мне например, не нравится QT или в том или ином окружении (ARM,MIPS,Power,QNX) оно не доступно для использования или глючит. При жёсткой зависимости от фремворка и результат использования системы будет один - не использование. В случае с существующей архитектурой GUI, да и почти всё, может быть реализовано на различных технологиях в виде отдельных модулей. Тот же GUI уже сейчас есть на QT и Web, а может быть не сильно трудно написан на Java, GTK+, WxWidgets, QNX-Photon и т.д. И очевидно, что шансов адаптироваться под конкретное окружение в таком случае значительно больше.
Все мои выкладки проистекают из условий и требований к системе OpenSCADA, заложенных, сформулированных и тщательно прописанных в проекте, в самом начале разработки, в 2003 году!
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 24. 06. 2009 [12:18]
|
|
Nerobarain
Мансуров Асхат
Создатель темы
Зарегистрирован(а) с: 23.06.2009
Сообщения: 3
|
Спасибо за столь детальный ответ. Некоторые подводные камни мне небыли видны сразу. Теперь ваша точка зрения и чем оно обусловлено стало понятно.
|
|
Сообщение создано: 25. 06. 2009 [09:11]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
Пожалуйста
Learn, learn and learn better than work, work and work.
|
