У нас своя отработанная, по самое не хочу оттестированная и главное навязывающая определенный стиль написания приложений иерархия классов и конторолов для PB 9.0.2. Она гораздо более легкая, чем PFC, но не менее функциональная (расширенные возможности DW, визарды, фильтры, и т.д.), которая правда строго ориентирована и интегрированна с решениями, реализованными на ASA 9.0.2. Соотвествующе я вообще не помню, когда последний раз у меня бы упала IDE или приложение в runtime. Правда стоит учитывать, что вся бизнес-логика полностью сосредоточена на WatcomSQL, отчеты на FastReport, соотвествующе клиент настолько легок и прозрачен, что там особо и не чему падать то, кода практически нет :)

JustVasНе флейма ради, но интереса для :) не сравнит ли всезнающий All PB и Delphi в сфере проктирования клиент-сервер...
А чего их сравнивать. В качестве чистого клиента 2-х звенки однозначно на PB можно разрабатывать гораздо быстрее и качественнее с более легким сопровождением, но с небольшими НО ... PB нужно хорошо знать, использовать по назначению, СУБД должна быть достаточно мощной в функциональном плане и проектировщик БД достаточно грамотным, чтобы все что нужно выносить в БД и бить по рукам кодеров, если они пытаются бизнес-логику запихивать на клиентскую часть (а еще лучше на уровне доступа к БД их сразу ограничивать жесткими правилами взаимодействия клиентской части с ней).

rcryo ASCRUSУ нас своя отработанная, по самое не хочу оттестированная и главное навязывающая определенный стиль написания приложений иерархия классов и конторолов для PB 9.0.2. Она гораздо более легкая, чем PFC, но не менее функциональная Думаю не один я заинтрегован. Если не трудно и не секрет, можно поподробнее. Некий изначальный меморандум на основе которого строился этот фреймворк и, возможно, структура. Будет хоть что обсудить на этом форуме, а то так и будем до конца жизни выяснять вопросы типа "как пройтись по всем колонкам в DW"
"Выделенной документации" как таковой естественно нет, поэтому сложно чего то внятное рассказать. Естественно есть иерархия классов, однако она небольшая, например весь функционал, расширяющий DW находится как раз в базовом классе DW. Я бы сказал, что основная идея моих библиотек (не важно на чем они были написаны) всегда сводится к тому, что в них закладывается строгая и отработанная парадигма работы с конкретной методикой, конкретным пользовательским интерфейсом и ориентацией на конкретную СУБД. Это нельзя назвать универсальностью, фактически это жестко навязываемый стиль и принципы работы программисту клиентской части, где существует централизованное управление логикой интерфейса, расширения под конкретную СУБД, позволяющие сокращать кол-во действий при программировании бизнес-логики и собственно говоря сама бизнес-логика конкретных режимов. Каждая часть отвечает за свое, поэтому в бизнес-логике программист думает исключительно о бизнес-логике, а не о том, кто кого будет вызывать, как правильно нужно сохранять и т.д. Сюда же в концепцию вписывается и класс-обвязка моего COM-сервера на базе FastReport, где по тому же принципу программист сосредотачивается на самом отчете, а не проблемах, как сделать сложный отчет с такими то прибамбасами (например шахматку) и как дать возможность экспортить его в Excel (как раз вчера например нужно было выгнать в Excel отчет с данными, однако в листе Excel еще расписать колонки с формулами для аналитиков, которым этот отчет был нужен, чтобы забить туда предполагаемые цифры и посмотреть, сколько это выйдет в деньгах - на FastReport справились на ура, фактически нарисовав Excel макет прямо в FR и черех экспорт уже получив сразу нужный результат без каких либо манипуляций с OLE).

В итоге можно сказать по моим библиотекам:
1. Никакой универсальности и шагов в сторону - СУБД однозначно ASA9, интерфейс по виду и принципам работы типизированный для всех наших приложений (хочу заметить, что удобный, чтобы слово типизированный не ассоциировалось с всякими 1С). Никаких "пользовательских" форм, динамической генерации и сборки DW, и т.д.
2. Однотипный в пределах конторы код клиентской части PB и отчетной FR.
3. Высокая скорость разработки с учетом того, что централизованное управление интерфейсом и компоненты повторного использования есть, остается дописать только бизнес-логику, которая опять же ничего архисложного из себя не представляет, так как в основном это рисование обычных DW, иногда примитивный код на PowerScript, вводящий какие то дополнительные действия (например при изменении поля на первой странички визарда включить/отключить следующие зависимые странички).
4. Отсутствие падений IDE и RunTime - весь код в библиотеках выверен и работает, кода в самом клиентском приложении чрезвычайно мало, поэтому и падать особо нечего. Падения если и бывают, то происходят в основном из за глюков PB при обращении к БД через ODBC/OLE DB.

Какие библиотеки есть:
asc_System
- служебные классы, такие как аналог n_Application, коллекции, коллекции именованных параметров, система сообщений, система глобальных переменных.

asc_Func
- функции, которых явно не хватает в PB

asc_WinApi
- описание внешних функций (WinApi)

asc_DataWindow
- расширенный DataWindow, расширенный Transaction, дерево данных на базе TreeView, окно логина с авт. сохр. логина посл. пользователя, окно уведомления об ошибке с 2 вкладками (сообщение для пользователя и реальное сообщение с сервера, с синтаксисом вызова DW и трассировкой вызовов с самого сервера), различные фунции (вызов обработки ошибок после ESQL, получение Increment или GUID и т.д.)

asc_Interface
- главное окно, дочерние окна, система уведомлений всех окон о произошедших событиях, различные функции управления toolbar, меню и т.д.

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

asc_Filter
- визуальный компонент и на его базе готовое модельное окно вызова запроса параметров фильтрации. Весь механизм работы фильтра реализован на ASA, где описываются схемы фильтров, группы (запросы), параметры (поля запросов), отработка фильтра (сбор SQL-скрипта, выполнение и возврат найденных id обьектов). Так же есть поддержка сохранение по пользователям установленных параметров фильтров для повторного использования. В PB визуальный компонент все это считывает, организует визуальное представление, выдавая на указанную схему группы и их параметры, учитывая при вводе параметров по их типу, какое DW наиболее подходит к соотвествующему типу, есть поддержка выбора значений параметров из списка, где можно указать собственный DW для этой цели. После установки пользователем значений всех нужных параметров фильтра, PB передает управление ASA, которая формирует SQL-скрипт, выполняет и сохраняет полученные ID в указанную таблицу по текущему коду пользователя, что соотвествующе позволяет другим модулям приложения PB или отчетам FR всегда знать, с кем на текущий момент они работают.

asc_FastReport
- класс, обвязывающий COM-сервер FastReport, окно управления отчетами (дизайнер, предварительный просмотр и печать, выгрузка отчета с БД в файл и загрузка с файла в список отчетов БД, блокировка отчета пользователем, для запрета его изменения или просмотра до его разблокировки), пользовательское окно выбора отчетов с поддержкой выбора по группам отчетов. Так же функции управления отчетами без окон (например, установка глобальных переменных отчета для организации отчета с нужной формы сразу по ее полям).

Все библиотеки используют решения друг друга, так что по отдельности их использовать нельзя. Через asc_n_Application и asc_n_Transation организовано дополнительное внутреннее взаимодействие всех компонент библиотек, которое не требует явного управления. Все спроектировано с учетом повторного наследования, соотвествующе функционал компонентов можно далее продолжать расширять в нужную сторону. Из обязательных требований: наличие глобальной переменной asc_n_Application GNAPP и обьявление SQLCA как asc_n_Transaction (ну или наследованные от них классы).

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

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

rcryoцентрализованное управление интерфейсом. В качестве примера, как в ЦУИ укладывается представление данных об объекте в виде формы с несколькими закладками, на каждой из которых данные из связанных таблиц.

В главном окне все дочерние формы в основном только на просмотр. Соотвествующе организовать при движении по фильтру перечитку данных на выбранный в фильтре обьект во вкладках пару строчек кода (чуть ниже я размещу скриншот).

rcryoasc_Filter. лучше один раз увидеть
Скриншот ниже.

rcryoкласс, обвязывающий COM-сервер FastReport ваш собственный или разработчики уже сделали?
Собственный. Они сейчас делают "универсальный", то есть тот, который на уровне интерфейсов будет достаточно гибко управляться "по желанию" клиентского приложения. Мой сервер наоборот централизованный и всю логику работы с отчетами (вплоть до организации подключения к БД для отчетов и их подгрузку, сохранение в БД, блокировки отчетов и т.д.) берет полностью на себя. Даже удаление отчета из таблицы делает не PB, а сам сервер, PB просто вызывает у него нужный метод.

К этому сообщению прикрепляю скриншоты последнего запущенного проекта.

Окно работы с договорами, слева договора активного фильтра, справа информация по всем параметрам выбранного договора:

Начало работы визарда на ввод нового документа по договору:

Окно выбора параметров активного фильтра (все описания поднимаются с ASA):

Список доступных отчетов в клиентском приложении:

Менеджер отчетов, сделанный на PB в виде отдельного приложения и позволяющий регистрировать, добавлять, изменять и удалять отчеты, с поддержкой командной работы (блокировка/разблокировка на время дизайна отчета) и многопрофильности (через ini возможность описать БД, в которых лежат отчеты и переключаться между БД в рунтайме).

Почти во всех РСУБД есть 4 вещи, которые позволяют сделать все перечисленное Вами (правда не у всех качественная или полная реализация):
1. Таблицы, которые помимо хранения самих данных проекта позволяют элементарно описать типы обьектов и операций, а так же их параметры.
2. Триггера, которые позволяют нам полностью контролировать изменение информации и автоматически производить проверки, расчеты и другие действия.
3. Язык хранимых процедур, который можно рассматривать как интерпретируемый мощный язык работы с множествами.
4. Динамический SQL, позволяющий нам на лету генерить и выполнять скрипты на языке хранимых процедур, вплоть до генерации самих хранимых процедур.

Исходя из перечисленных 4-х пунктов можно в БД описать логику какой угодно сложности - документооборот, автоматическую генерацию бухгатреских проводок по операциям, реализацию расширения типов документов и операций, и т.д. Например, здесь я описываю реализованный на ASA генератор ХП и HTML по шаблонам, с поддержкой вложенных секций, переменных и курсоров, языка макроподстановок, который сам реализован на WatcomSQL.

Так что лично я считаю, при граммотно проектировании метаструктуры описания обьектов, их параметров и связей, при отсутствии ограничений в РСУБД на использование динамического SQL, а так же проблем с ним у оптимизатора - проектирование бизнес-логики в БД не такая уж сложная задача. Ко всему прочему Вы получаете минимум кода (обработка не одного, а сразу всего множества однотипных документов через запросы), максимум скорости (централизованная обработка в пределах сервера, без передачи всех данных, необходимых для расчета клиенту по сети) и легкость сопровождения и отладки (рисуем собственный бак-офис на базе таблиц метаструктуры описания обьектов, для отладки ХП, зарегистрированных на методы и свойства обьектов используем встроенные средства самой РСУБД, те же профайлер, отладчик, консультант индексов и графический план запросов). Такая схема будет разрабатываться и потом сопровождаться гораздо легче, чем ООП, где необходимо тщательнейшим образом продумать иерархию интерфейсов и классов, написать на языке более низкого уровня реализацию, потом по мере расширения проекта все равно столкнуться с тем, что разработанные интерфейсы все равно не покрывают новых потребностей, соотвествующе искать "обходные" пути для решения этих проблем и через 2-3 года самому запутаться в куче классов, где что есть, и кто кого и зачем вызывает :)

P.S. В этом плане я приверженец динамического описания обьектов и кода, считаю правильным движение Питона, думаю что именно это во многом обеспечило успех DataWindow и очень жалею, что PowerSoft не сделал PowerScript интерпретируемым, с возможностью генерации классов и компонентов динамически "на лету" прямо со строковой переменной, как это сделано в Питоне.

rcryoна какой стадии сейчас проект MacroSQL. Можно ли на него взглянуть?
На стадии "работает" и честно генерит по макетам триггера и процедуры в тех проектах, где задействован :) Глянуть то можно, только вот отсутствие внятной документации и примеров использования делает это "глянуть" как мне кажется бессмысленным номером :( Давайте пока отложим это на лето - я тут призадумался написать под ASA на самой же ASA систему контроля версий скриптов (прямо на ASA веб-сервисах), заодно там можно будет организовать собственное хранилище повторно-используемых решений, куда войдут системные функции, процедуры, обьекты фильтров, визардов и MacroSQL. Все равно в хозяйстве порядок наводить надо, причем хочется ведение версий скриптов обьектов БД как то автоматизировать, то есть опять же жестко это ПО завязать только на ASA.

zenkЯ несколько скептически отношусь к перекладыванию функций клиента на сервер при написании выверенных приложений. Как мне кажется, в таких проектах затруднено создание качественного пользовательского интерфейса.
Базовые вещи можно реализовать через серверные процедуры, но релизовывать скрытие/показ полей, условное форматирование и начальные проверки проще на клиенте. У нас как сделано: сначала пользователь вводить документ, при этом работает в основном клиент: проверяются даты начала и конца, набор реквизитов для документа и т.п. Часть условий проверок хранится в базе. Затем уже сохранённый документ регистрируется ("проводится"). Здесь работает сервер, так как при этом проверяется взаимоувязка этого документа с остальными объектами в базе.
А я нигде и не говорил, что у нас логикой интерфейса занимается БД. Интерфейс не является бизнес-логикой и как его реализует клиентское приложение честно говоря БД до лампочки. Так же клиент может заниматься любыми проверками вводимой информации, если это организовывается легко и нет усложнения кода. Однако в любом случае последней инстанцией на проверку информации будет именно БД и даже если клиентское приложение частично проверило данные, на сколько ему было не сложно, БД в любом случае будет проверять все - это гарантирует целостность и правильность данных вне зависимости от того, кто что и как проверял и через чего в БД попала информация - через клиента или ISQL. Тоже самое касается и расчетов и дополнительной обработки информации - все делает БД, соотвествующе если код в БД выверен, то мы имеем 100% гарантию того, что данные в БД всегда будут правильными. Это более правильно, чем размазывать бизнес-логику между 2 платформами и на выходе из за ошибок и недочетов программистов клиентской части получать неправильные данные или же натыкаться на ситуацию, когда нужно подключить к БД еще сторонее клиентское приложение/удаленный сервер/сервис, а часть бизнес-логики уведена в клиентское приложение.

В общем я не понимаю, чем может быть вызвано скептическое отношение к централизованному управлению данными (активные БД), я наоборот скептически отношуюсь к решениям, где народ предпочитает бизнес-логику уводить на клиентскую часть. IMHO я думаю это происходит только по 2 причинам:
1. Нехватка функциональных возможностей РСУБД
2. Незнание/не умение пользоваться всеми преимуществами РСУБД.