AlexKBИнтересна тема SMWrap + Cache.


Сталкивался я с этой связкой:
SMWrap - хорошая поделка, но не более того.
В основном используются людьми в годах, которые знают mumps/cos
и не способны изучить что-то новое.

Основные недостатки такие:
1. Java, С#, Delphi его полностью перекрывают по всем показателем
(начиная от скорости выполнения и разработки до возможности написания собственных компонент)
2. Идея управления окнами из Cache сама по себе порочна (СУБД
должна заниматься БД, а не управлением контролов в окнах; и cos
заточен именно под работу с данными)
3. При данном подходе на СУБД и сеть создается большая и по сути
ненужная нагрузка (передача событий, их обработка и возврат).
4. Проблемы с сопровождением: больше ошибок, трудней найти людей,
надо платить большую ЗП т.к. инструмент экзотичен.

ИМХО: Берите инструмент из п.1 в зависимости от задачи.

PS. Для расширения кругозора можете глянуть аналогичную поделку
от компании Эскейп-М: http://www.escape.ru/technologies/guiclient.html

WWW BoyКак именно это сделать? Я обращался к ним, но в отличие от SMWrap этот инструмент строго внутренний, просто так не ставится и не дается. Что-то изменилось? Хотелось бы поподробнее на тему столь уверенного "можете глянуть".
"просто так", возможно, и не дается. Придется ограничиться описанием на сайте.

WWW Boy Ruslan22. Идея управления окнами из Cache сама по себе порочна (СУБД
должна заниматься БД, а не управлением контролов в окнах; и cos
заточен именно под работу с данными)

Классика мампса - терминальные приложения. Чем они занимаются как не отрисовыванием окон?
СУБД (Cache в частности) занимается обработкой данных.
А управлением окнами должен заниматься клиент и/или сервер приложений.

WWW Boy Ruslan23. При данном подходе на СУБД и сеть создается большая и по сути
ненужная нагрузка (передача событий, их обработка и возврат).

В отличие от терминальных как раз нагрузка поменьше будет. Пока идет ввод текста в поле ввода клиент smwrap вводит текст на клиенте. Отсылка на сервер - по событию. В терминальных - каждое нажатие кнопки это работа текстового редактора написанного на мампсе.
1. Я сравнивал не с терминальной архитектурой, а с клиент-серверной и/или трехзвеннкой (см. п.1)
2. Помимо текста SMWrap шлет на сервер еще win-события (ReSize,Close,Change и т.п.), что до СУБД вообще не должно доходить
WWW Boy Ruslan24. Проблемы с сопровождением: больше ошибок, трудней найти людей,
надо платить большую ЗП т.к. инструмент экзотичен.
Как выяснилось, все снова наоборот: проще найти дельфийца и объяснить десяток новых команд мампса, чем найти еще одного мампсера. С кадрами под smwrap как раз проблем не было.

Разговор идет не о Cache, а об инструменте SMWrap (см. subj)
соответственно:
проще и дешевле дельфийца, чем "найти дельфийца и объяснить десяток новых команд мампса"

LittleCat Ruslan2
2. Идея управления окнами из Cache сама по себе порочна (СУБД
должна заниматься БД, а не управлением контролов в окнах; и cos
заточен именно под работу с данными)


Позвольте с Вами не согласиться. Идея заключается в том, что пользовательское приложение управляется не кодом, а данным. Что делает программист дельфи и иже с ними, когда меняется техзадание и нужно модернизировать клиента ? Правильно, он бежит переписывать код и потом обновлять клиентскую часть на всех компьтерах. Что делает разработчик, использующий инструмент типа SMWrap ? Он меняет описание в базе данных, и вот уже на всех местах приложение выглядит по-новому ! А если к этому добавить простоту языка MUMPS и скорость разработки, то вопрос о цене вопроса становится весьма спорным :-)

1. Клиентская часть на рабочих местах обновляется автоматически - Delphi это умеет.
2. Речь шла не о хранении клиентской части на сервере, а об обработке событий на стороне СУБД. Возьмем сервер-ориентированную архитектуру - CSP: страницы храняться на сервере, но первичная обработка событий выполняется на клиенте (например, Cache не ловит resize окна, потерю полем фокуса - этим занимается Javascript из загруженной на клиента HTML-страницы)

AlexKBДа, действительно MSM это трактор, причем карьерный.
Лично мне очень нравилась связка MSM-NT + MSM-WS на клиенте.

Жаль что после слияния Intersystems и Micronetics так и не появилось своего родного, для Cache, GUI-инструментария.
Хуже другое - Intersystems не занимается созданием ERP-системы на
основе Cache (Microsoft подвигает Navision, а Oracle - OEBS).
Вместо этого был сделан Ensemble - достаточно спорный проект.

По моим сугубо личным прикидкам через 7-10 лет в основном будет
вестись разработка под конкретную ERP-платформу: для автоматизации
предприятия будет браться ERP-система; ее профильные для предприятия
модули будут либо переписываться в рамках идеологии выбранной системы,
либо стандартный модуль будет сильно кастомизироваться. Разработка
с использованием СУБД в чистом виде значительно сократится.
Если к этому моменту Intersystems не представит на рынке продукт
сравнимый хотя бы с устаривающей SAP R/3, то ниша Cache
сузится окончательно.