RunBase vs SysOperationFramework для Excel отчета

[gl00mie]

По-моему, любой нормальный импорт, работающий с клиентскими данными, должен идти примерно так:

• запуститься на сервере;
• запустить "нечто" на клиенте (возможно, 2-й экземпляр себя же по аналогии с RunBase.promptPrim()), чтобы считать "сырые" данные на клиенте и вернуть их на сервер;
• прогнать на сервере цикл разбора/проверки/сохранения импортированных данных со всей сопутствующей бизнес-логикой.

для экспорта - аналогично, но с чуть иной последовательностью шагов.
От импортов/экспортов/отчетов в Excel, которые всё делают на клиенте, меня лично коробит.

[kitty]

Цитата:

Сообщение от gl00mie

От импортов/экспортов/отчетов в Excel, которые всё делают на клиенте, меня лично коробит.

Клиенту нужны бантики и рюшечки, которые только в экселе можно сделать
Т.е спец оформление таблиц, фиксация колонок и тд.

Вопрос:
Есть класс собирающий данные (MyCalcClass, RunOn:Server), есть класс выгрузки всего в эксель(MyExcelClass, RunOn:Client)
Если мы используем SysOperation framework, то как лучше организовать вызовы:

1) Контроллер вызывает серверный MyCalcClass. Когда данные рассчитались, MyCalcClass внутри себя вызывает MyExcelClass и передает ему рассчитанную таблицу.

2) Контроллер вызывает клиентский MyExcelClass , который внутри вызывает серверный MyCalcClass. MyCalcClass возвращает рассчитанную таблицу и MyExcelClass ее использует для выгрузки.

Мне кажется, второй вариант совсем сводит на нет возможные преимущества sysoperation, тк по сути клиентский код управлет всем. Может, правда , и нет вообще разницы.

[gl00mie]

Цитата:

Сообщение от kitty

Есть класс собирающий данные (MyCalcClass, RunOn:Server), есть класс выгрузки всего в эксель(MyExcelClass, RunOn:Client)
Если мы используем SysOperation framework, то как лучше организовать вызовы?

Можно применить шаблон Model-View-Controller (MVC). В приведенном описании MyCalcClass можно классифицировать как модель (данные), MyExcelClass - как представление (вывод собранных данных в Excel, а не, скажем, в html или визуализация в виде диаграммы). Координацию их работы логично возложить на контроллер (как в терминах MVC, так и в терминах SysOperation framework), передачу же собранных данных из модели в представление можно реализовать через выходной контракт класса, собирающего данные. Если в этом контракте реализовать сериализацию, то можно будет существенно сэкономить на RPC-вызовах.

[Napalm]

Цитата:

Сообщение от gl00mie

По-моему, любой нормальный импорт, работающий с клиентскими данными, должен идти примерно так:

• запуститься на сервере;
• запустить "нечто" на клиенте (возможно, 2-й экземпляр себя же по аналогии с RunBase.promptPrim()), чтобы считать "сырые" данные на клиенте и вернуть их на сервер;
• прогнать на сервере цикл разбора/проверки/сохранения импортированных данных со всей сопутствующей бизнес-логикой.

На RunBase так сделать очень просто. А с SysOperationFramework есть хоть один пример такого решения?