автор Т.е. в своей системе я могу в большинстве случаев хоть откуда - хоть из asp.net - дернуть ХП и сделать какое-то "бизнес-логическое" действие, т.е. ХП внутри себя сделает чего-то, призведет манипуляции с данными. вызовет еще n ХП - и в результате получится некоторое доведенное до логического окончания действие. Например провести заказ в статус, или переместить товар и т.д. Мне для это нужно в большинстве случаев всего то написать exec MyStoredProc @id = ... и все.
Это частный пример, можно делать все, что угодно. И не всегда есть необходимоть/возможность/время запускать клиента.
В случае же Bold получается, что так никак не сделать. Потому что только клиент контролирует всю логику работы системы.

Ты невнимателен. Посмотри на описание - про COM - клиентов.

авторНу БД то тоже кэширует данные, и неплохо это делает :)
Кэширование на клиенте несет совсем иную смысловую нагрузку. Ты о таком режиме не слышал?

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

Ты невнимателен. Есть механизм пропагаторов.

авторТем более что если отсутствуют нормальные способы оптимизации, то на фиг такая система.

Система есть, но "нормальна" ли она для каждого отдельно взятого девелопера?

авторНо как-то меня не прикалывает вызывать COM-объект для того, чтобы например перевести заказ в нужный статус.
Это проще, чем кажется. Но конечно, насильно мил не будешь.

авторНу или мы говорим о кэшировании данных, или о чем-то другом. Если о первом, то ..... совсем уж не иную.

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


авторВнимателен:
Невнимателен.

авторКак другой клиент увидит изменения, если их в БД еще нет? То, что он узнает об изменениях, не поможет. Или propagator рассылает измененные данные? Не думаю что-то. А если не рассылает - то чтобы другой клиент увидел изменения, первый клиент должен их положить на сервер БД. Беда, беда. Привык ты к кусорам всяким, не понимаешь. Вот пример. На экране юзера отображается два поля - Фамилия и Имя. Юзер извлек эти поля не по принципу SQL - "select и зыбыл", а получив унакальный идентификатор объекта. Об получении этого объекта он известил пропагатор, и попросил его извещать обо всех изменениях, сделанных с этим объектом (подписалься на этот объект). Ну, вот, когда кто-то меняет объекты, эти кто-то извещают пропагатор об изменениях. Если ты подписался на эти объекты, то получаешь от пропагатора соотв. сообщение, и повторно отфетчивешь объект. А выглядит все очень прикольно - ты сделал изменение в фамилии - и все юзеры через положенное время увидели результат. Скажи - такое приработе РСУБД возможно в общем виде, с отображением произвольной структуры вьюх? Я лично объяснял заказчику, что это не нужно, потому что он не понимает своей выгоды от не-реализации такой фичи. А тут - все на поверхности.

авторКак кэширование изменений связано с потрясающей скоростью? Все еще не понятно.

авторА если не рассылает - то чтобы другой клиент увидел изменения, первый клиент должен их положить на сервер БД.

Извини, пропустил. Да, конечно, когда КЛИЕНТ посылает данные на сервер, только тогда пропагатор и начинает работать. Т.е. "у себя в кармане" копайся сколько влезет, а как кидаешь все на сервер - пожалте через пропагатор. Тут еще про механизм блокировок и про регионы поговорить нужно.

Тигра, опять ты меня развел... Очень уж ты эмоционален. Хорошо хоть, что общаемся в виртуале.

авторКакие курсоры? Я их видел то два раза за год. Что, не знаю чтоли, как извещения работают?
Только при чем тут вьюхи???

Ну да, вьюхи тут не причем. Я имею в виду, что то, что получил клиент с сервера (в обычной к-с системе) - это как на бумаге отпечатано. Ну, получил ты результаты запроса типа

, смотришь на него, а редактировать без написания соотв. update - sql не можешь. А в данном случае не можешь в принципе. Потому что Id__t1, Id_t2 не присутствуют в выборке.


авторНу сделать подписку на изменения можно и в обычной к-с системе, и не так сложно. Но нужно ли? Лишний трафик, кстати :). Но если сильно нужно - да нефиг делать, сделаем. :)
Хорошо тебе. Умный ты.
Ну, а тут все это есть изначально.

авторНу так и к-с так же делает.
Ну, да, есть такой режим.

авторИ так и не понятно - где тут скорость? Где скорость, зависящая именно от кэширования технологией Bold? Скорость чего? Можно ли конкретный пример, чтобы было видно, что и как ускорилось?

Извини, не понял вопроса.

PL99 mv...Ну, получил ты результаты запроса типа

, смотришь на него, а редактировать без написания соотв. update - sql не можешь. А в данном случае не можешь в принципе. Потому что Id__t1, Id_t2 не присутствуют в выборке.


Ничего не понял. Редактировать с сохранением в БД без написания update невозможно. Так и никто не может редактировать. А вот если t1.Field1, t2.Field2 - альтернативные ключи - то очень даже можешь редактировать

Ага! Попался один! А вот в Bold мы работаем не с копией данных, а с самими данными! И там такое делается как само собой разумеющаяся вещь.

авторА я обычно ИД-шники включаю. И с успехом редактирую :) Через вызов ХП.
Да понятно.

авторА всегда ли нужно, вот в чем вопрос. Зачем зр трафик жрать, на БД нагрузку. А то подписаны 100 клиентов на один объект, а он изменился. И все 100 в БД полезли. Тормоза начались..... А зачем? Если из них только трем эти изменения нужны.
Ну, ты даешь! Если тебе что-то не нужно, то же не делаешь этого? Если только трем нужны - то пусть только три и пописываются :)

авторДавай еще попробую: каким образом кэширование изменений приводит к потрясающей скорости? Пример очень желателен - без и со скоростью.
Извини, Тигра, но для меня эти вещи как сами собой разумеющиеся - попробуй, к примеру, К-С прогу сделать, что быстрее - когда ты на каждый чих лезешь на сервер, начинаешь транзакцию, отсылаешь запрос, потом заканчиваешь транзакцию, или когда пакетом данные обновляешь?

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

А я вот - наоборот. Стараюсь упрстить процесс разработки.


авторНу хорошо, позволила эта технология быстро разработать систему. А сопровождать? Ну разработали мы вместо полгода за два месяца - а потом вдруг оказалось, что поддержка настолько тяжела, внесение изменений настолько трудо и времяемко, получение отчетов и другой информации обычными способами из БД вообще невозможно, тормоза страшные а оптимизация в следствие зашитости логики и запросов в клиента так гиморно производится, что ............. а ну его нафиг такую систему, пусть заказчик сам с ней ...%;№"*?: А сопровождение - просто сказка. Изменение структуры модели/базы/репликации - ух, как здорово. Но домой уже пора.

Пока.

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

Месяц работал, сюда не заглядывал... Мдя...

Неужели так никто и не заинтересовался системой?

Все мазохисты, что ли, или так любят низкоуровневое программирование?

Смотрите, в Delphi 2005 система ECO позиционируется как центральное новшество. Останетесь на остановке со своими ХП/Триггерами, а поезд с MDA дальше уедет!

Если кому интересно - появилось масса доков по-русски, да и опыт в разработке / отладке / оптимизации Bold for Delphi. Пишите.

Всем привет и счастливо оставаться!

Ну да, вот аттач-то

Andr2 Начали копать помаленьку.
Правда сразу начали смотреть в сторону TBoldCOMServerHandle (DCOM),
когда сама модель на сервере лежит (типа классической трехзвенки).
Есть ли наработки/опыт/грабли в этом направлении или стоит плюнуть ?
Просто в инете нашлось всего две ссылки по этой теме.
Дальше - что там с отчетами не очень ясно.
Еще - что-нибудь про разработку в Bold-е для команды (принципы, особенности и тд)
Ну и про доки на русском - можно ссылки, или на е-mail за посылкой приходить ? :)
Про ECO vs Bold пару слов послушать бы. Где-то мелькало, что служба качества Borland пока не пропустила Bold в 2005.
Если есть инфа по новым реализованным проектам (в т.ч. по своим) - тоже интересно.

Насчет работы в команде - где-то читал, найду, скажу. Ну, тут мне представляется вообще идеал - выкладываешь для общего обозрения/юзанья ядро с моделью и интерфейсами к ней, и каждый рубит в своем направлении - кто ГУИ, кто дополнительную функциональность в коде и проч. Главное - все работают с одной моделью. И число девелоперов должно кардинально снизиться. (Да и где их много взять-то под Bold ?:-)

Ну, TBoldCOMServerHandle у меня еще впереди, похоже. ХОТЯ ТЕСТЫ ГОНЯЛ, И НИКАКИХ ПРАКТИЧЕСКИХ ПРОБЛЕМ НЕ ЗАФИКСИРОВАЛ. Ну, может, не так удобно, как при двухзвенке - типа, OCL - конструкции "ручками" писать придется. Хотя есть Clientifier, можно попробовать.

Насчет отчетов - ну, что за трабла? Если есть старые привычные, DB - ориентированные генераторы - врубаешь TBoldDataSet - и вперед. А еще есть пакет BoldRave. Халявный. Вот здесь.

ECO. Автор книжки (К.Грибачев) про это рассказывал, он был одним из бета - тестеров Delphi 2005. Говорил, что развивается помаленьку, все лучше и лучше. Хотя у него (да, честно говоря, и у меня) душа к .Net не лежит. Пока. Жизнь заствит, и мы перейдем...

Проекты. Недавно злобные руководители заставили реализовать систему хранения документов. COM/DCOM клиент/сервер. С произвольной системой раубрикации документов, настройкой уровней отображения и т.п. Так вот, за три недели от постановки задачи до реализации полностью реализовал и переработал три практически независимые модели. Вариант с раелизацией стандартными средствами (для меня это было примерно так - ErWin <-> InterBase <-> Delphi с метанием туда-сюда) отпал почти сразу из-за ограниченных сроков. Руководство просто пищит. Зарплату подняло.
Предполагамый рабочий объем базы - 20~50 гигабайт. Потестили в жестких условиях, работает с приемлимой скоростью. Хотя пришлось оптимизировать, конечно. Да, оптимизация тут - просто абассацца... (отдельный разговор). Объем модели (на сегодняшний день) небольшой - 17 классов, число пользователей в сети - до сотни, предполагаем юзать механизм пропагатора. Ну, не вполне устраивают стандартные контролы (карасиво хотца), будем RAD Studio (Bold Edition) покупать.

Еще проект - пока заморожен - до февраля - система дистрибуции. На данный момент реализованы компоненты (Bold - aware) для рисования схем и диаграмм, оттачивалась схема модели. Очень классно, - меняешь значение в ОП - а на картинке прямоугольник меняет свои координаты/размеры. И наоборот. Ну, это только заготовки для работы. Вся работа еще впереди.

Да, еще знакомые забацали штуковину, из тех, что сейчас модно CRM называть. За неделю. С диаграммами Ганта, сложными выборками/отображениями и т.п.


Насчет доков. Вот тут кое-что (из попытк перевода + собственные домыслы) см. аттач.)

... и как это я умудрился перепутать местами два последних сообщения?

Ну, еще разные штуки/доки есть, но они большие, а аттач не влазят.

Один mv
Проекты. Недавно злобные руководители заставили реализовать систему хранения документов. COM/DCOM клиент/сервер. С произвольной системой раубрикации документов, настройкой уровней отображения и т.п. Так вот, за три недели от постановки задачи до реализации полностью реализовал и переработал три практически независимые модели. Вариант с раелизацией стандартными средствами (для меня это было примерно так - ErWin <-> InterBase <-> Delphi с метанием туда-сюда) отпал почти сразу из-за ограниченных сроков. Руководство просто пищит. Зарплату подняло.
Здорово ! Особенно про зарплату. Вот это - реальный эффект :)
А чего DCOM используется ? Ведь эта технология уже мхом поросла.

А почему бы не юзать предлагаемые готовые решения, если они уже есть?

авторДа кто же против ? Речь о том, что технология распределенных приложений у MS развивалась так:
DCOM (позавчерашний день) - COM+ (вчерашний) - Remoting (сегоднешний) - Indigo (завтрашний, на тек. момент не существует)
Если разработчики Bold не захотели связываться с .Net (Remoting) , что понятно, то почему бы не взять хотя бы COM+ ?

Да пофиг вообще, что за система тебе интерфейсы предоставляет, хоть Corba...
Я имел в виду частный случай - использование утилиты EntrprisePropagator. Не нарвится - пиши свои сервисы, тем более, что все довольно прозрачно...

Главное тут - в MDA, а остальное - рюшечки.