29.08.2017, 10:55 | #10 |
Участник
|
Цитата:
Если собираешься продолжать в таком же духе подмены понятий, то, пожалуйста, воздержись от участия в этой ветке. Буду очень признателен. Для тех же, кто хотел бы разобраться. Вопрос: ПОЧЕМУ? ЗАЧЕМ сделано или не сделано именно так? Цитата:
Но снова приходим к тому, что альтернативно-перпендикулярных возможностей было дофига и больше. Почему выбрано именно это? Случанойсть или таки было что-то, что не видно? =================== Из личных обсуждений у меня возникает стойкое ощущение, что я плохо сформлировал "что есть" и "что могло бы быть" - народ просто не врубается. Итак, старый добрый SysOperationProgress: * одна операция один класс * в одном классе замешаны хранилище данных, маршаллинг данных, диалог, собственно обработка * допускается наследование классов-обработок * предоставляется фреймворк, от которого надо унаследовать свой класс и встроиться в фреймворк * отлаживать надо один класс * класс полностью управляет своим состоянием, инициализацией и восстановлением параметров, отображенем себя в UI. В частности, сам занимается отображением своего прогресса и прочим информированием пользователя о своем состоянии. Новый SysOperation (уже обсужался неоднократно): * несколько формально и синтаксически независимых, но при этом очень сильно семантически связанных классов * наследовать от базовых классов не нужно (нет базовых классов) * встраивание во фреймворк происходит через атрибуты (и соответственно, через рефлекшн) * создание классов-наследников от собственного происходит с трудом (потому что атрибуты не наследуются) * класс обработка (в стандарте) не занимается своим состоянием, инициализацией и восстановлением параметров, не имеет доступа к UI. В частности, не может отображать прогресс и не может информировать пользователя о своем состоянии. по сути изменений два: 1. вместо наследования - не наследуемые атрибуты 2. вместо все-в-одном - группа очень тесно связанных классов 3. вместо обычного класса - обязательно сервис Супер-новая штука в ax7 SysOperationSandBox (не обсуждался): * класс-обертка для фреймворка SysOperation * позволяет написать один вызов, чтобы вызывать * отображает на экране инфо-окно специального вида. =================== Собственно какие альтернативы были: например, миксины вместо атрибутов (и рефлекшн) пойти в interface и наследование от интерфейсов. другими словами, написать интерфейсы для datacontract, service, controller не требовать, чтобы это были отдельные классы, а позволить создавать любые классы, которые имплементируют интерфейсы. в старой доброй аксапте уже начали ходить в эту сторону. См. runbase, enumerator и прочие. (см. скриншот ниже) по крайней мере, не сломалось бы наследование. хотя, соглашусь, гибкость такого решения чуть меньше, чем у атрибутов. но и разбираться было бы легче. почему не пошли дальше? зачем сменили курс? =================== я абсолютно не верю в то, что между клиентом и сервером невозможно передать данные. потому что вижу примеры других систем, где эти данные вполне передаются. также вижу и аксапту с ее "новым" инфологом. поэтому не катит. я абсолютно не верю в то, что на передачу данных идут какие-то большие накладные расходы. извините. я абсолютно не понимаю, почему нельзя было отрисовать форму на клиенте в рамках старого доброго SysOperationProgress. однако вижу, что кто-то принял решение - SysOperationProgress не нужен. лично меня абсолютно не устраивает "объяснение" в стиле "Не все теоретические возможности на практике реализованы." Меня не интересуют ВСЕ теоретические возможности. И возможности SysOperationProgress вовсе не теоретические. Считаю ответ в таком стиле чистой воды демагогией. Я хочу понять логику этого товарища (или группы товарищей) в отношении SysOperationProgress, SysOperation, SysOperationSandbox. Я хочу понять ПОЧЕМУ? Понять я хочу, чтобы эффективно использовать это понимание в своей работе. И сделать продукт более конкурентноспособным. Последний раз редактировалось mazzy; 29.08.2017 в 11:17. |
|