Любое программное обеспечение основывается на модели, 
которая была сформирована в голове главного архитектора системы в конкретный период времени. 
Эта модель достаточно стройная на момент начала её реализиции, за исключением белых пятен, 
которые присутствуют на границах этой модели. 
Но в любом случае эта модель - компромис между знаниями ТЕКУЩИХ технологических возможностей,
используемой главным архитектором системы, и выкладками специалистов-предметников, 
на описаниях которых строится адекватная модель области деятельности, подлежащей реализации. 
Со временем реализации программного проекта изменяется среда проекта, а именно
- появляются новые технологии в разработке программного обеспечения,
- накапливается опыт применения уже внедренного программного комплекса,
и что самое главное 
- происходит расширение кругозора у архитектора системы в предметной области
и
заказчиков ПО в технологиях ИТ.
В результате появляется осознание факта, 
что первоначально заложенная в основу системы модель не совсем соответствует текущему представлению модели.
Но на этом этапе возникает понимание, что изменить существующее ПО довольно трудно, 
т.к. слишком много "жестких" связей между инструментом пользователя программного комплекса и структурой хранения данных.
Что делать в такой ситуации?
Если отличия первоначальной модели от текущего представления о ней не существенны, 
то можно провести перемоделирование проекта и провести этап доработки.
Если различия между моделями существенны, то необходимо полное перепроектирование системы
с сохранением компонентов системы, функционал которых не изменился в новой модели. 
Для наименее болезненного преодоления таких этапов 
в последнее время всё активнее используются некоторые новые технологии 
для прохождения с наименьшими временными и человеческими затратами
этапов описания-проектирования-программирования, например язык UML.
Зачастую это подходит под описание MDA(архитектура управляемая моделью).
Но как было точно подмечено в литературе по MDA наиболее узкое место в таком способе проектирования заключается в том, 
что ОБЪЕКТНО-ОРИНТИРОВАННОЕ клиентское программное обеспечение нужно состыковывать с РЕЛЯЦИОННОЙ системой хранения данных.

Все вышеописанное пропущено через себя с тем только исключением, 
что архитектор системы и специалист-предметник в моем случае - одно и тоже лицо, я.
Т.к. скорость расширения моего кругозора в сфере программирования и в предметной сфере были достаточно высоки,
то скорость изменения представления модели, которая должна была заложенной в ПО, была ещё выше.
В результате пришлось 3 раза полностью переписывать клиентское ПО.
Но т.к. мои возможности слишком скромные, то в новом клиентском ПО были реализованы только новые функции,
и соответственно одновременно существовали 3 версии клиентского ПО. 
Самое печальное то, что старые клиенты не позволяли изменять структуру базы данных,
т.к. в них были прописаны поля таблиц данных.
В итоге появилось желание сделать клиента и базу данных независимыми друг от друга.

Были сформированы предварительные требования к предполагаемой системе.

1. клиентское приложение должно общаться с источником данных, 
используя только один протокол передачи данных и работать с разными базами данных.
Решение - клиент взаимодействует по протоколу сокетов с промежуточным ПО, 
которое в свою очередь взаимодействет с серверами баз данных.
Применение механизма сокетов позволяет клиентскому приложению работать через интернет с удаленными базами данным,
т.е. клиент получился универсальным, как для локальной сети офиса, т.к. и для удаленных рабочих мест.

2. клиентское приложение должно иметь один стандарт данных для обмена с промежуточным ПО.
Решение - для обмена применяется стандарт XML, вернее его "цифровая упаковка" ClientDataSet из библиотеки midas.
Применение ClientDataSet как на стороне клиента, так и на стороне промежуточного ПО позволяет избежать
затрат на парсинг, что существенно повышает скорость работы комплекса.

3. клиентское приложение не должно содержать в коде никаких ссылок на структуру базы данных,
т.е. должно выполнять функции универсального браузера ЛЮБОЙ базы данных.
Решение - на стороне промежуточного ПО была создана специализированная база данных,
в которой хранились описания данных из подключаемой к клиенту базе данных, 
необходимых для отображения в клиенте. В этой базе хранятся описания наборов данных,
возвращаемых клиенту, комманды для управления наборами данных (select,insert,update,delete),
описания полей датасета, описания входных параметров набора данных,
описания коллекций наборов данных, которые должны находится на одной форме
клиентского приложения и т.д.

4. клиентское приложение должно иметь ограниченный набор инструментов для отображения и управления данными,
полученными в виде абстрактного набора данных.
Решение - набор данных отображается в стандартной форме, у которой всегда имеются следующие элементы управления -
2 панели ToolBar, одна для стандартных операций с набором данных - копирования, удаления, фильтрации и сортировки записей,
вторая - для отображения кнопок управления конкретным набором данных, как правило для перехода на форму детализации
выбранного поля набора данных, исходя от его текущего значения.
Набор данных отображается в Gride, при редактировании в котором датасет накапливает дельту изменений,
которая впоследствии передается в промежуточное ПО для сохранения изменений датасета.
Входные параметры датасета для формирования на их основе акутального селекта отображаются на форме 
в виде DbLookup-элементов соответствующих для типа данных входных параметров, 
например для типа данных Date используется календарь. Положение входных параметров датасета определяется настройками
в базе данных словаря.

5. промежуточное ПО должно обеспечивать доступ к любой источнику данных, как серверам баз данных,
так и к источникам XML-данных, получаемыми например от веб-серверов.
Решение - промежуточное ПО получает данные с помощью драйверов баз данных с последующей переупаковкой данных
в стандарт ClientDataSet для передачи клиенсткому ПО в пределах локальной сети.
Также оно поддерживает механизм сеcсий клиентского ПО, чтобы исключить зависание клиента на стадиях ожидания ответа,
а также например для подстановки идентификатора клиента в качестве значений в сохраняемые наборы данных,
возвращенных от клиента.
Для доступа к удаленным базам данных предусматривается возможность каскадного включения экземпляров промежуточного ПО.




Фактически речь идет о платформе для "супер быстрого" проектирования ИТ-систем, 
которая позволяет как быстро смоделировать систему "с нуля" для её опытной эксплуатации,
так и бесшовно провести интеграцию между существующей системой и доработками функциональности системы,
когда нет возможности внести изменения в структуру основной базы данных и доработка должна хранить данные
в отдельной базе данных.

Что самое главное - данное ПО позволяет сосредоточиться именно на реализации своих ноу-хау с фиксацией модели 
в структуре базы данных без заморочек с программированием клиента.