ax7: SysOperationSandbox - пример использования. почему именно такая архитектура?

[mazzy]

Цитата:

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

Да, теоретически такая возможность есть. Не все теоретические возможности на практике реализованы.
...
Я уже высказал свое мнение по этому поводу в соответсвующем треде.

Ясно. Спасибо, Макс, за твое очень ценное мнение.
Если собираешься продолжать в таком же духе подмены понятий, то, пожалуйста, воздержись от участия в этой ветке. Буду очень признателен.

Для тех же, кто хотел бы разобраться. Вопрос:
ПОЧЕМУ? ЗАЧЕМ сделано или не сделано именно так?

Цитата:

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

Ты уже почти ответил на свой вопрос Какая из этих технологий пренадлежит MS? Даст ли использование этих подходов приемущество в патентных войнах?

Ок. Предположим.
Но снова приходим к тому, что альтернативно-перпендикулярных возможностей было дофига и больше. Почему выбрано именно это? Случанойсть или таки было что-то, что не видно?

===================
Из личных обсуждений у меня возникает стойкое ощущение, что я плохо сформлировал "что есть" и "что могло бы быть" - народ просто не врубается.

Итак, старый добрый SysOperationProgress:
* одна операция один класс
* в одном классе замешаны хранилище данных, маршаллинг данных, диалог, собственно обработка
* допускается наследование классов-обработок
* предоставляется фреймворк, от которого надо унаследовать свой класс и встроиться в фреймворк
* отлаживать надо один класс
* класс полностью управляет своим состоянием, инициализацией и восстановлением параметров, отображенем себя в UI. В частности, сам занимается отображением своего прогресса и прочим информированием пользователя о своем состоянии.


Новый SysOperation (уже обсужался неоднократно):
* несколько формально и синтаксически независимых, но при этом очень сильно семантически связанных классов
* наследовать от базовых классов не нужно (нет базовых классов)
* встраивание во фреймворк происходит через атрибуты (и соответственно, через рефлекшн)
* создание классов-наследников от собственного происходит с трудом (потому что атрибуты не наследуются)
* класс обработка (в стандарте) не занимается своим состоянием, инициализацией и восстановлением параметров, не имеет доступа к UI. В частности, не может отображать прогресс и не может информировать пользователя о своем состоянии.

по сути изменений два:
1. вместо наследования - не наследуемые атрибуты
2. вместо все-в-одном - группа очень тесно связанных классов
3. вместо обычного класса - обязательно сервис

Супер-новая штука в ax7 SysOperationSandBox (не обсуждался):
* класс-обертка для фреймворка SysOperation
* позволяет написать один вызов, чтобы вызывать обработку фреймворка SysOperation произвольный статический метод произвольного класса.
* отображает на экране инфо-окно специального вида.


===================
Собственно какие альтернативы были:
например, миксины
вместо атрибутов (и рефлекшн) пойти в interface и наследование от интерфейсов.
другими словами, написать интерфейсы для datacontract, service, controller

не требовать, чтобы это были отдельные классы, а позволить создавать любые классы, которые имплементируют интерфейсы. в старой доброй аксапте уже начали ходить в эту сторону. См. runbase, enumerator и прочие. (см. скриншот ниже)

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

почему не пошли дальше?
зачем сменили курс?

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

я абсолютно не верю в то, что на передачу данных идут какие-то большие накладные расходы. извините.

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

однако вижу, что кто-то принял решение - SysOperationProgress не нужен.
лично меня абсолютно не устраивает "объяснение" в стиле "Не все теоретические возможности на практике реализованы."
Меня не интересуют ВСЕ теоретические возможности.
И возможности SysOperationProgress вовсе не теоретические.
Считаю ответ в таком стиле чистой воды демагогией.

Я хочу понять логику этого товарища (или группы товарищей) в отношении SysOperationProgress, SysOperation, SysOperationSandbox.
Я хочу понять ПОЧЕМУ?

Понять я хочу, чтобы эффективно использовать это понимание в своей работе. И сделать продукт более конкурентноспособным.

[macklakov]

Цитата:

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

Понять я хочу, чтобы эффективно использовать это понимание в своей работе. И сделать продукт более конкурентноспособным.

У меня сложилось впечатление, что разработчки и консультанты на партнерах и клиентах не рассматриваются как клиент. Поэтому язык и инструментарий делаются под нужды продуктовой команды. И поэтому ими очень неудобно пользоваться на внедрежах.
Т.е. если нужен инструментарий удобный для внедренца, его надо писать отдельно. Но т.к. удобство внедренца в приоритетах не значится, систему неожиданно изменят и инструмент придется преписывать заново. По этой причине хороших инструментов на рынке мало. И по этой причине на внедрежи в бюджет не укладываются и бывают проблемы с прохождением аудита. И поэтому продукт агонизирует. И поэтому на замену AX выстраивается линейка 365 компонент.