Цитата:
Сообщение от
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.
Я хочу понять ПОЧЕМУ?
Понять я хочу, чтобы эффективно использовать это понимание в своей работе. И сделать продукт более конкурентноспособным.