2 Dima T
автор каркас не может обеспечивать расчеты в приложении, логика приложения индивидуальна для каждого проекта

А что, разве для логики обработки и расчетов невозможно сделать класс-"обёртку" (или несколько взаимодействующих классов) ?
Тем более, что по технологии доступа к данным уже имеется объектная модель курсор-адаптера...

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

Не согласен с данным утверждением уважаемого автора Dima T. В знак чего привожу пример концептуального подхода, который можно применить при создании класса обработки данных.

Итак, в основе обработки данных лежит процесс, реализующей логику расчетов и сами расчёты.

1. Имеем перечень участвующих в процессе таблиц, описание связей между ними, используемые индексы (короче, метаданные).

2. Процесс, по сути - это некая процедура навигации, т.е. «обхода» по записям заданной таблицы. Будем называть её «главной» таблицей.

3. Диапазон обрабатываемых записей «главной» таблицы определяется условиями типа :
• только текущая запись,
• запись, найденная по ключу (или по связи),
• по логическому условию и т.д. .

4. Типы выполняемых действий над записями «главной» таблицы:
• удалить,
• изменить.
• только чтение.

5. «Главная» таблица имеет связи типа «ведущий-ведомый» с другими таблицами, реквизиты которых могут быть считаны при переходе на очередную запись «главной» таблицы процесса.

6. Обход «главной» таблицы идет по определенной сортировке (или без таковой, физическим порядком)

7. После установки на очередную запись выполняются переходы на записи в подчиненных таблицах. После чего, собственно, можно выполнить сами операции по обработке. Это могут быть :

• Простейшие формулы.
• Структурные конструкции типа IF,CASE.
• Вызовы других процессов.
• Вызовы функций и процедур.
• Добавление записей в другие таблицы (заметьте, что в п.3 нет пункта типа «Добавить», так как в этом случае просто нечего «обходить»). В этом случае «главная» и связанные с ней таблицы являются источником данных для той таблицы, в которую идет добавление.

Разве это сложно выполнить в виде универсального класса ?

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

Dima T…при создании оберток все выигрыши в производительности могут потеряться из-за увеличения времени на работу оберточного кода.

Корреляция между количеством «оберточного» кода и производительностью работы программы (с субъективной точки зрения пользователя) при современном уровне развития аппаратных средств неумолимо стремиться к нулю. Тем более, что большую часть машинного времени в программном обеспечении информационных систем составляет работа по считыванию и записи данных непосредственно на носители.

Dima T
Я в своем посте писал про бизнес-логику конкретного приложения, которая выходит за рамки нормальных форм реляционных БД.

Не следует путать разные понятия: «бизнес логика» как набор абстрактных правил, сформулированных в терминах понятных для конечного пользователя и «нормальные формы реляционных БД» как модель неизбыточного хранения структурированной информации и её непротиворечивой модификации, которую явил свету дедушка Ф.Кодд. За рамки «нормальных форм» может выйти только концепция OLAP-хранилищ, где структура данных умышлено денормализуются для быстроты доступа к оным для получения сложных агрегированных ретроспектив.

Dima T
Она (бизнес-логика) уникальна для каждого проекта и напрямую зависит от его предметной области. Что общего между складским учетом, расчетом зарплаты и ведением истории болезни в больнице?

Да, для кладовщика, главбуха и врача их деятельность не имеет ничего общего . Но это взгляд с точки зрения конечного потребителя, который в своей работе оперирует конкретными атрибутами своей предметной области. Этот взгляд лишен элементов абстрактного восприятия, которое принципиально необходимо для создания модели бизнес-логики, которую можно будет затем доверить машине. А «бизнес-логика» с точки зрения абстрактной модели как раз и состоит из тех самых элементарных «процессов», структуру и механизм действия которых я и предложил выше и «это» есть то самое «общее», о котором спрашивает Дима Т .

Что ж, в догонку помещу здесь еще ссылочки на 2 фрэймворка (так сказать, для коллекционеров) …
http://www.luxsoft.by (см. Инструментальную систему «Квант», надо будет с них за рекламу взять :=)) )

http://www.visionpace.com (Visual Maxframe Professional, the object-oriented framework for creating state-of-the-art Visual FoxPro applications.)
… и подведу сюда свою жирную черту следующего вида.
Все фрэймворки, которые мне пришлось видеть обладают одной интересной особенностью. Они мне нравятся с точки зрения получаемого вида и возможностей создаваемых с их помощью программ (и то не все !). Но мне совершенно не устраивает то, какой ценой это достигается. Копаться в бесконечных лабиринтах библиотек визуальных классов, выясняя иерархию подчиненности классов, перечень и описания их свойств, методов, копипастить во всевозможных текстовых файлах, содержащих параметры каких-то понятных только разработчику фрэймворка настроек, полный отрыв между описанием структуры данных и компонентами доступа к ним (иногда по причинам отсутствия метаданных как таковых). Я такого мазохизма как-то не хотел бы себе позволять.
В общем, мне кажется, что разработчик в этом случае перегружен чрезмерным числом технических деталей, не получая в таких фрэймворках должного уровня абстрагирования. Опыт и интуиция подсказывает мне, что уровень Project Manager, Menu und Form und Report Disainer и проч., предлагаемых средой Fox-а недостаточен (тем более, что общеизвестен факт наличия обоснованных нарекания на предлагаемый ими перечень возможностей и функционал, т.к. MS умышлено «клал прибор» на эти вопросы по сравнению со своими новыми средствами, дабы не создавать внутренней конкуренции между продуктами).
Предлагаю взглянуть на вопрос с точки зрения архитектуры фрэймворка и оценить возможность её реализации средствами FoxPro, по-прежнему подразумевая безупречность языковых и рантаймовых возможностей фокса, базис которых был заложен задолго до MS.

Фрэймворк должен состоять из :
• репозитория прикладных объектов, построенного на реляционных таблицах,
• набора инструментария для редактирования атрибутов прикладных объектов репозитория (т.е. работа разработчика идет вне средств среды FoxPro),
• исполнительная часть, которая выполняет чтение и интерпретацию содержимого репозитория и представляется конечному пользователю как прикладное решение, годное к применению.

В целом , напоминает устройство 1С. Но 1C написан на С++, неужели то же (и даже лучше) нельзя выполнить средствами Fox?

Sergey ChFoxPro, если Вам не известно - создавался как Framework для C++...

Ну, да. Конечно, же мне об этом не докладывали ...
Зато мне известен факт того, что FoxPro - это Framework не для C++, а для разработки программ обработки реляционных баз данных, написанный на C++. И я сейчас хочу затронуть вопрос возможностей данного Framework-а, насколько он помогает решать поставленные задачи в данной области.

Sergey Chписать Framework для Framework довольно бесперспективное занятие
Я считаю, что если бы FoxPro был бы нормальным Framework-ом, то тогда не было бы нужды городить то, что представлено в данном топике. Это всего лишь доказательство того, что есть нужда в более высоком уровне абстрагирования и я предлагаю его еще более повысить на основе изложенной выше архитектуры.
Тем более, что подобную стратегию используют многие не-Fox-ориентированные платформы. И, по-моему, в Фоксе есть все, чтобы решить подобную задачу, и мало что есть для решения прикладных задач в лоб (унификацию кода, библиотеки всяческих классов в расчет не беру - это нужно, но не достаточно!).

Sergey Chмы все через это уже прошли Мы "все" - это кто? Приведите, pls, пример каких-либо подобных "прохождений". А то, что это гимнастика для мазгов, так то … Даа… Местами даже смахивает на акробатику под куполом! И все же, неужели все так плохо ?
Dima T
Повторюсь, кроме дедушки Ф.Кодда наверно никто не видел "неизбыточного хранения", поэтому задача хранения и поддержание целостности избыточной информации ложиться на разработчика, а не на СУБД
Согласен, но это уже проблема не хранения информации, а взаимодействия OLTP (приходы и расходы) и OLAP (обороты и остатки) подсистем между собой, которая опять-таки решается с помощью совокупности «процессных» процедур и выбором необходимого уровня детализации в хранении аналитической информации (номенклатура, партия, цвет, размер) и интервалов временных ретроспектив в OLAP-подсистеме (т.е. интервал хранения остатков – по дня, по неделям, по декадам, по-месячно, по-квартально и т.д.) .
Dima T, мне трудно судить о том, почему продукты 1С тормозят: по понятным причинам я и многие из нас не видели исходники данного продукта и по этой причине не могут произвести должный анализ всех причин. Возможно, там имеются какие-либо проблемы. К примеру, SAP AG, развиваясь более 30-ти лет, таких проблем не имеет. Так что у 1С ещё все впереди. Я словно летчик-испытатель, который верит в критический момент своей машине и заставляет её вытворять всякие опасные фокусы. Так же и я надеюсь на Fox в вопросе построения на его базе эффективного FrameWork-a, т.к. для этого имеются технологические предпосылки: развитая инфраструктура рантайма, макроподстановки, динамическая генерация и исполнение параметризованного кода, поддержка Aсtive-X и OLE-Automation, технологии ООП, COM, XML и RushMore, язык, «заточенный» под обработку данных и проч. Ведь некоторых из этих элементов в Visual C++ нет и разработчикам 1С приходилось создавать их заново в рамках собственной компонентной модели. А по чём же мы можем судить о качестве их изготовления? Может там и имеются какие-либо изъяны, влияющие, в том числе, и на производительность 1С.

2Dima T.
Предложение поучаствовать меня заинтересовало, спасибо. Скинь, пожалуйста, на olb@tut.by сообщение для связи, изложу подробности: их накопилось уже немало и есть что тестить ...

ЗЫ:
Спасибо участникам кто откликнулся на мои замечания не по теме для данного топика. Прошу прощения у Protean-а за то, что отвлекал внимание народа от содержания его вопроса. Все приятного летнего отдыха !