guest_20072707Здравствуйте!

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

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

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

заранее спасибо! :)

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

Основные способы использования БД:

1. Генерация интерфейса на основании расширенного meta dictionary.
2. Использование БД для хранения шаблонов форм и ассоциации их с сгенерированной частью.


Могу добавить ряд преимуществ:

1. Возможность улучшения процесса автоматического тестирования
2. Генерация шаблонов хелпа и документации.
3. Возможность быстрой смены и одновременной поддержки разных клиентов, например: десктоп и веб.
4. Быстрота построения прототипа для показа заказчику.


Основные проблемы:

1. Оптимальным образом работает, если на клиентской стороне - интерпретатор.
2. Сложность сохранения результатов кастомизации в случае изменения структуры базы.

Реализации:

1. 1992-1994. Clipper. Результаты: Падение трудозатрат в среднем в пять раз после внедрения системы. Один из компонентов системы получил приз СА за наиболее богатую функциональность и лёгкость настройки.

2. 1997. Delphi/Oracle. Один из результатов : Выигрыш, после показа прототипов, тендера на автоматизацию одного из крупных украинских холдингов. Модифицированная система используется по сей день.

3. 2003-2004. Частичная реализация (порядка 90%). SQL Server + XML/XSLT + web client. Результат: Поддержание двойного интерфейса web client + IP phones. Система первой получила сертификат Cisco (разработка пользовательских аппликаций для четвёртого С).

4. 2003-2007. Частичная реализация. Результат: Одновременная поддержка .Net/web client. Опережение конкурента при соотношении ресурсов 5:1 в пользу конкурента привело к покупке компании. Конкурент вышел из бизнеса. Одной из главных причин выбора был назван интерфейс.

Mainframe_старыйВ среду была на предзащите докторской диссертации на тему автоматизация разработки пользовательского интерфейса на основе онтологического подхода. Если интересует, поищите статьи Грибовой В. в журналах Информационные технологии. Совсем скоро на сайте ВАК выложат реферат по техническим наукам. И сам реферат можно прочесть и там будут ссылки на ее статьи. В основном применяется в системах, где тербуется ввод многих параметров, при этмо параметры дополняются - меняются. В частности реализованы сситема для медицины, для автомото предприятия и для косметологии. Там текстовые данные вводятся, выводятся статические рисунки и простая динамика.

На эту тему пишут докторские? :) Очень интересно:) У человека должен быть богатый опыт создания подобных систем. Или это на теоретическом уровне? "Обоснование возможности создания.."?