wxWidgets vs Ultimate++
wxWidgets vs Ultimate++
Привет!
Скажите, пожалуйста, у кого-нибудь есть опыт использования обоих платформ. В чем лучше начинать делать проект, для работы с БД?
Скажите, пожалуйста, у кого-нибудь есть опыт использования обоих платформ. В чем лучше начинать делать проект, для работы с БД?
Заканчиваем проект на wxWidgets и активной работой с базами данных.
Идея простая и хорошо себя зарекомендовавшая уже лет 10. Не делаем никакой привязки "GUI-база данных". Из базы прочитали в вектор затолкали, на гриде показали, поредактировали, ... В базу данных записали. Тот же вектор если надо с "листбоксе", "чойсе" показали.
Были правда небольшие проблемы с DatabaseLayer-ом, и есть проблемы с построителем отчетов.
Для отчетов пока обошлись wxPdfDoc. Делаем в для него шаблон в котором наши специальные теги, в них данные и подставляем.
Если тебя GPL не ограничивает и несть время прикрутить wxDatabaseLayer к ISQLReport, то можно пробовать его юзать.
Вот так оно выглядит
Идея простая и хорошо себя зарекомендовавшая уже лет 10. Не делаем никакой привязки "GUI-база данных". Из базы прочитали в вектор затолкали, на гриде показали, поредактировали, ... В базу данных записали. Тот же вектор если надо с "листбоксе", "чойсе" показали.
Были правда небольшие проблемы с DatabaseLayer-ом, и есть проблемы с построителем отчетов.
Для отчетов пока обошлись wxPdfDoc. Делаем в для него шаблон в котором наши специальные теги, в них данные и подставляем.
Если тебя GPL не ограничивает и несть время прикрутить wxDatabaseLayer к ISQLReport, то можно пробовать его юзать.
Вот так оно выглядит
Большое спасибо за описание вашего опыта. У меня тогда к Вам еще пару вопросов, если можно.vtararin wrote:Заканчиваем проект на wxWidgets и активной работой с базами данных.
...
Вектор стандартный std::vector или wx вариант?
Есть ли необходимость показывать большие объемы, тогда вроде бы хранить в массиве становится не выгодно?
- T-Rex
- Moderator
- Posts: 1248
- Joined: Sat Oct 23, 2004 9:58 am
- Location: Zaporizhzhya, Ukraine
- Contact:
Это лучше чем для виртуального ListView например подгружать постоянно из БД значения. Особенно если сервер не embedded (да хотя и у embedded тоже быстродействие не ахти).Есть ли необходимость показывать большие объемы, тогда вроде бы хранить в массиве становится не выгодно?
Delphi например весь рекордсет в памяти хранит.
Узаем std::vector.
Интерфейс построен так, что пользователю нет необходимости смотреть огромные объемы данных.
Мы исторически (с 1996 года) выработали стратегию, показывать пользователю не более 2000 записей при запросе. Если зпрос возвращает больше, то уведомляем пользователя и пусть работает с фильтром. Ни разу ни одного нарекания от пользователя не было.
Так что вопрос со скролированием больших объемов и не стоял, а 2000 объектов в ОЗУ это совсем не много.
При работе с базами скролирование через базу данных - это плохая затея. Есть СУБД которые не поддерживают скролирующиеся курсоры совсем (Oracle 7 и 8, PostgreSQL 7,8.0 например), есть СУБД которые сбрасывают курсоры при окончании транзакций (Interbase например), есть СУБД которые при чтении (скролировании) выставляют блокировки по чтению (MSSQLServer, уровень изоляции не грязное чтение). И в любом случае - это очень сильно повышает нагрузку на сервер.
Интерфейс построен так, что пользователю нет необходимости смотреть огромные объемы данных.
Мы исторически (с 1996 года) выработали стратегию, показывать пользователю не более 2000 записей при запросе. Если зпрос возвращает больше, то уведомляем пользователя и пусть работает с фильтром. Ни разу ни одного нарекания от пользователя не было.
Так что вопрос со скролированием больших объемов и не стоял, а 2000 объектов в ОЗУ это совсем не много.
При работе с базами скролирование через базу данных - это плохая затея. Есть СУБД которые не поддерживают скролирующиеся курсоры совсем (Oracle 7 и 8, PostgreSQL 7,8.0 например), есть СУБД которые сбрасывают курсоры при окончании транзакций (Interbase например), есть СУБД которые при чтении (скролировании) выставляют блокировки по чтению (MSSQLServer, уровень изоляции не грязное чтение). И в любом случае - это очень сильно повышает нагрузку на сервер.
У меня вот еще вопросы появились
Если использовать wxWidgets, то возникает желание использовать Boost, там много разных вкусностей. Это нормальное желание?
И по поводу БД и многопользовательского режима. Вот скажем есть некая таблица с номенклатурой, которую могут редактировать несколько человек как лучше делать синхронизацию? Перечитывать ли таблицу раз в какое то время? Либо посылать уведомления об изменении обходными путями? Что делать в случае добавление, или что хуже в случае удаления записей?
Если использовать wxWidgets, то возникает желание использовать Boost, там много разных вкусностей. Это нормальное желание?
И по поводу БД и многопользовательского режима. Вот скажем есть некая таблица с номенклатурой, которую могут редактировать несколько человек как лучше делать синхронизацию? Перечитывать ли таблицу раз в какое то время? Либо посылать уведомления об изменении обходными путями? Что делать в случае добавление, или что хуже в случае удаления записей?
- T-Rex
- Moderator
- Posts: 1248
- Joined: Sat Oct 23, 2004 9:58 am
- Location: Zaporizhzhya, Ukraine
- Contact:
Ну, скорее нет чем да. В wxWidgets есть нормальные контейнеры и вобще возможностей вполне достаточно для нормальной работы.Если использовать wxWidgets, то возникает желание использовать Boost, там много разных вкусностей. Это нормальное желание?
Там вон про синхронизацию, дык тоже есть wxCriticalSection, wxMutex, ну в общем все как у людей. Хотя да, никто не запрещает юзать boost но особых выгод в этом не вижу. Опять же, на вкус и цвет фломастеры разные.
Это зависит от многих факторов, в основном от предметной области приложения. И выходит далеко за рамки wxWidgets.DmP wrote:как лучше делать?
Почитайте хорошую книжку по СУБД, от корки до корки и там все найдете.
И обязательно по той СУБД которую будете использовать.
Кстати, реализовать стратегию на основе версий строк с использованием wxDatabaseLayer не удасться, т.к. он не предоставляет кол-во измененных записей на операциях update и delete, а без этого не работает. Хотел было эту фичу прикрутить, но времени совсем нету.
По большому счету wxDatabaseLayer нужно перелопатить по образу и подобиюT-Rex wrote:Может в bounties вывести этот таск и студентам показать?
zeoslib. Сейчас изать его довольно тяжело, сыроват он и концептуально и в реализации.
- T-Rex
- Moderator
- Posts: 1248
- Joined: Sat Oct 23, 2004 9:58 am
- Location: Zaporizhzhya, Ukraine
- Contact:
Скачал zeoslib, гляну на досуге.
А по поводу Databaselayer, ну, jb_coder вроде автор, как-то он так консервативно к багрепортам относится. я как-то постил пару раз, толку ноль. надо самому фиксить.
С другой же стороны я вижу выход не в переделывании DatabaseLayer а в апгрейде wxARG до вменяемого вида, чтобы оно хотя бы со старту компилилось и работало корректно. Мне например wxARG очень по душе.
А по поводу Databaselayer, ну, jb_coder вроде автор, как-то он так консервативно к багрепортам относится. я как-то постил пару раз, толку ноль. надо самому фиксить.
С другой же стороны я вижу выход не в переделывании DatabaseLayer а в апгрейде wxARG до вменяемого вида, чтобы оно хотя бы со старту компилилось и работало корректно. Мне например wxARG очень по душе.