AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 13.01.2019, 20:28   #6  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5813 (201) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Мне кажется, подобно тому, как начинающие разработчики в прежних версиях упускали, где (на сервере или на клиенте) в какой момент времени будет выполняться тот или иной метод их наследника RunBase, сейчас дискутирующие упускают то, кто будет писать исходный класс на основе SysOperation или RunBase - и кто потом будет его расширять Наверно, стоит ввести некую классификацию разработчиков в данном контексте:
  • SYS-разработчики (условно) - разработчики стандартного приложения
  • ISV-разработчики вертикальных решений, устанавливаемых на нескольких внедрениях
  • USR-разработчики (условно) - авторы модификаций на тех или иных конкретных проектах внедрения
В разрезе такой классификации чисто комбинаторно можно выделить такие сценарии:
  1. SYS-код кастомизируется ISV-разработчиком
  2. SYS-код кастомизируется USR-разработчиком
  3. ISV-код кастомизируется USR-разработчиком
  4. ISV-код кастомизируется ISV-разработчиком, разрабатывающим свое сторонее ISV-решение, которое должно уметь устанавливаться вместе с другим ISV-решением.
  5. USR-код кастомизируется USR-разработчиком
Возможности менять код через расширения интересны, по-моему, в сценариях 1, 2 и 3, причем в сценарии 3 - при условии, что ISV-модель закрыта для overlaying'а. В то же время, ISV-решения зачастую поставляются с исходниками и при этом не закрыты для overlaying-а. Сценарий 4 - это какая-то экзотика, как мне кажется; если же есть два ISV-решения одной и той же компании, то там можно придумать более естественные возможности кастомизаций: всякие там события-делегаты, интерфейсы + inversion of control и прочая. Использование расширений в сценарии 5 мне лично кажется не очень естественным: не понятно, зачем так поступать в реальной жизни.
Цитата:
Сообщение от trud Посмотреть сообщение
Идея sysoperation конечно изначальна была хороша, но никто не стал ее развивать.
Развивать в сторону чего, возможности использовать механизмы расширений?
Цитата:
Сообщение от trud Посмотреть сообщение
Сейчас RunBase это единственный способ писать расширяемые классы(с PU22 даже обещают через CoC). Расширения DataContract недоступны. Плюс иногда нужны доп. возможности, к примеру внутри класса управлять задачами, создавая подзадачи
Полагаю, эти утверждения сделаны с позиции ISV-разработчика, который желает закрыть свой код от overlaying'а для USR-разработчиков SYS-разработчики вряд ли принимают во внимание такие нюансы, а USR-разработчикам без разницы, потому что свой собственный код или код коллег им нет надобности менять через extension-ы. Мне, например, как выступающему в роли USR-разработчика SysOperation в моих собственных модификациях более симпатичен и удобен, нежели RunBase. Но при этом от SYS- и ISV-разработчиков, я, наверно, ожидал бы скорее использования RunBase, чтоб у меня было больше возможностей при создании расширений
Цитата:
Сообщение от wojzeh Посмотреть сообщение
и опять выпустят фетву против runbase? нам-то чо делать: крестик снимать или...?
Рассуждения про выбор между SysOperation и RunBase, как показано выше, существенно зависят от того, в какой роли вы выступаете (SYS/ISV/USR-разработчик) и про чей код говорите: свой или чужой, т.е. от сценария (1-5), в контексте которого идет обсуждение Для USR-разработчиков, по-моему, SysOperation предпочтительнее, потому что позволяет более четко отделить сервис от контракта и UI для интерактивного ввода параметров, что способствует повторному использованию сервисных операций в тех местах, которые изначально не предполагались. Наследников RunBase обычно использовать из стороннего кода менее удобно, потому что там часто не выделен четко контракт (банально не хватает parm-методов), плюс внутри могут быть какие-то неявные завязки на интерактивный запуск, скажем, инициализация по глобальным настройкам и т.п. SysOperation в этом плане как-то больше дисциплинирует что ли.

Последний раз редактировалось gl00mie; 13.01.2019 в 20:57.
За это сообщение автора поблагодарили: ta_and (4).
Теги
runbase, sysoperation framework

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
stoneridgesoftware: Batch Processing in Dynamics AX 2012 Using SysOperation Framework Blog bot DAX Blogs 0 28.03.2017 00:11
emeadaxsupport: Update to AX 2012 Framework Component Documentation: SysOperation Framework Blog bot DAX Blogs 0 09.06.2012 00:11
daxmusings: From RunBase to SysOperation : Business Operation Framework (Cont'd) Blog bot DAX Blogs 0 19.08.2011 16:11
daxmusings: From RunBase to SysOperation : Business Operation Framework Blog bot DAX Blogs 4 17.08.2011 16:01
Inside Dynamics AX 4.0: RunBase Framework Extension Part IV Blog bot DAX Blogs 0 02.10.2007 04:49

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 15:47.