ВорчунЕсть такая задумка. Разработать оболочку в которую на принцыпах плагинов можно внедрять любую начинку.
…
А затем добавляем любую функциональность. Каждый модуль (плагин) самостоятелен в пределах своей задачи (грубо говоря отделная программа работающая в общей среде). Это позволит постепенно перевести все самостоятельные задачи (разные программы) к единообразию, не прерывая работу организации.

Интересует может кто сталкивался с подобной задачей, какие подводные камни ждут впереди, и может подобный вопрос подымался на форуме?
(инструментарий: Delphi+MS SQL Server) Есть такая разработка, живая, много раз апробированная – БАС . Как раз инструментарий на Delphi+MS SQL Server. Один и тот же BAS.exe, одна и таже структура базы данных используются для различных задач. BAS.exe один для всех, а база данных одна для каждого прикладного модуля, плюс две общие базы: администора и системная.

На этом построены совершенно разные, с виду, прикладные модули. В бухгалтерии это Зарплата, Учет материалов, основные фонды, партнеры (поставщики, покупатели, и др.), финансы, бухучет. Есть учет производстве, экономическая подготовка производства. Другое направление – работа с населением – разные коммунальные предприятия и платежи населения с распределенной базой данной между поставщиками, банками, кассами, расчетным центром и ЖЭКами.

ВорчунОдна из обязательных баз - база справочников (АДРЕСА и КЛИЕНТЫ и пр.служебные таблицы). Обязательные базы – это системные. Все прикладные справочники надо размещать в базе данных специализированного модуля.

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

мод Aviant Единый Универсальный Интерфес Реализующий Любую Функциональность.
А потом окажется что реальная задача не "натягивается" на ваш engine

Должна быть иерархия инструментария:
1. базовые средства (языки, системы программирования и разработки)
2. универсальные модули (написаны на 1) (ведение справочников, генераторы экранных форм, генераторы отчетов. стандартные функции и процедуры и т.д.)
3. проблемно-ориентированные модули (разработаны на 2+1) (решение типовых прикладных задач)
Конкретная система разрабатывается (по убыванию приоритета):
3 - используются готовые решения +
2 - настраиваются универсальные модули +
2+1 - разрабатываются дополнителные алгоритмы и полностью оригинальные модули
При таком подходе ЛЮБАЯ задача "натягивается" на ваш engineА почему это называется "иерархия"? Может просто "функциональные возможности"?

ShtockГоспода,универсальный интерфейс конечно хорошо,когда оно надо :)
Но давайте попробуем посмотреть на тему универсального интерфейса чуть с другой стороны.
По сути его цель - добавлять какие-либо поля к формам отображения,ввода и прочим при появленииновых параметров сущностей.
Почему бы нам так не спроектировать структуру данных,чтобы она подразумевала добавление атрибутов как добавление новых записей в соответствующие таблицы и разработать интерфейс так,чтобы его не дорабатывать путем заполнения хитрейших интерфейсных справочников?!
Примеры:
1. Для справочника номенклатурных позиций пмсм (главное без флейма обойтись) замечательно подходит уже успевшая набить оскомину всем "модель" Тенцера. Интерфейс делается один раз: слева панель
с экземплярами объектов, справа при выборе конкретного объекта появляется аналог дельфийского ValueListEditor с двумя полями: имя атрибута и, соответствнно, его значение
2. Для описания взаимоотношений с клиентами строим структуру,позволяющую описать реальный мир на основе так
называемых ролей, отношений и прочего. Например,для описания того,что кто-то является банком кого-то не обязателно в таблице всех субъектов прибавлять ссылку на другого субъекта, но банка, а достаточно ввести такое понятие как роль "банк" и ввести отношение типа "является банком".Далее в таблицу, описывающую отношения субъектов (причем она должна быть продумана так, чтобы в одном отношении конкретного типа могли участвовать хоть 10 субъектов), пишутся соответствующие записи.
3. для описания договоров не бьем в таблицу договоров все его стороны, а делаем структуру БД так,чтобы для каждого типа договора был определен список типов субъектов, которые участвуют в данном виде договора, а для
конкретного договора заполняем табличку "Субъекты, принимающие участие в договоре."
4.Для описания набора булевских признаков группировки конкретного объекта используем стандартное дерево с иерархическим перечнем группКак только Вы пытаетесь применить прикладные особенности различных приложений к разработке универсального инструментального средства, то это средство сразу же перестает быть универсальным. Например, в конкретной реализации не требуются ни партнеры, ни договора, ни...