guest_20072707Здравствуйте!
Возможно, баян, но все же.
На каком-то форуме прочитал интересный топик о том, что можно из БД полностью генерить интерфейс приложения. Мне сразу же стала интересна эта тема и вот, что я вижу:
Вся бизнес-логика естессно на уровне БД (хранимые процедуры, функции и т.д.), там же хранится и описание того, как нужно построить интерфейс, то бишь описание объектов, свойств, методов. Exe-модуль содержит только модуль коннекта к БД и сам интерпретатор кода из БД.
Скажем, запускается приложение, производится запуск ХП для чтения информации об объектах системы (Справочники, документы), строится по этому описанию меню. По выбору конкретного пункта меню осуществляется вызов соответствующей ХП для чтения информации о выбранном объекте (описание формы, к примеру), при нажатии, допустим на кнопку производится опять-таки запуск соотв. ХП и "перечитывание" интерфейса из БД + выполняются необходимые действия...

Преимущества, которые сразу же бросаются в глаза:
1) существует возможность построения системы без необходимости частого обновления (оно будет нужно только иногда для обновления интерпретатора) во время этапа внедрения системы и сопровождения
2) интерефейс будет унифицирован

а вопрос следующий:
сталкивался ли кто-нибудь из форумчан с подобного рода системами? какие мнения существуют по этому поводу? только, пожалуйста, конструктивные предложения...

заранее спасибо! :)
Наша компания построила такую систему.
В БД, кроме пользовательских данных хранится:
- Элементы интерфейса.
- Свойства элементов интерфейса в разрезе пользователей.
- Пиктограммы к этим элементам интерфейса
- Шаблоны отчетов и других печатных форм
- Справка по системе
- Последняя версия исполнимого модуля (exe-шник), который автоматически обновляется при подключении
- может и еще чего, всего не упомнишь...

Система успешно работает уже лет пять у многих клиентов.

Что касается вышеописанных недостатков:
softwarer1. Такая схема полностью неспособна реализовать нестандартную функциональность, которая случается "в одной форме из ста" в любом серьезном проекте.
Поскольку в нашей системе не смешиваются данные прикладной области и данные платформы разработки, реализаию нестандартной функциональности можно прикрутить без проблем, заодно включив ее в стандартный функционал.

softwarer2. Во всех случаях, которые я видел, генерируемый интерфейс был элементарно некачественным. Происходит это, как мне представляется, по двум причинам...

У нас вроде качественный ). Дело в том, что в этой системе интерфейс просто хранится в базе данных. Процесс "раскраски" и "расстановки" контролов присутствует в том же виде, что и в продуктах Borland.

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

softwarer uraДело в том, что в этой системе интерфейс просто хранится в базе данных.
Cкажите пожалуйста, видите ли Вы разницу между словами "хранить" и "генерировать"?
конечно... если интерфейс хранится в БД, то соответственно он и генерируется в момент подключения к ней

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