Разница между runBase, sysOperationFramework и (формой+класс)

[Lankey]

Добрый день
У меня вопрос на понимание
D365
Есть у меня форма в шапке с Заголовком и внизу с линиями в гриде (как на форме закупок). По нажатию кнопки на форме пользователю должен быть показан диалог, где он вводит дату и интервал(int). По закрытию диалога поле Дата на линиях грида долно пересчитаться по формуле: дата текущей линии = дата предыдущей линни+интервал (есть нормер линии,поэтому поянтно, как считать)

Я могу
1) Cделать MenuItem, что открывает форму-диалог и в closeOk запустит класс , что обновит записи, и вызовет reread/refresh формы-родителя
2) RunBase, что сделает в одном классе и диалог и обновление. Но RunBase не в моде в D365 .
3) SysOperationFramework - будет 4 класса. Что, кажется, перебор

Как вы делаете выбор? Склоняюсь к первому варианту, тк коротко и ясно. Какие у него недостатки?

[sukhanchik]

Цитата:

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

Добрый день
У меня вопрос на понимание
D365
Есть у меня форма в шапке с Заголовком и внизу с линиями в гриде (как на форме закупок). По нажатию кнопки на форме пользователю должен быть показан диалог, где он вводит дату и интервал(int). По закрытию диалога поле Дата на линиях грида долно пересчитаться по формуле: дата текущей линии = дата предыдущей линни+интервал (есть нормер линии,поэтому поянтно, как считать)

Я могу
1) Cделать MenuItem, что открывает форму-диалог и в closeOk запустит класс , что обновит записи, и вызовет reread/refresh формы-родителя
2) RunBase, что сделает в одном классе и диалог и обновление. Но RunBase не в моде в D365 .
3) SysOperationFramework - будет 4 класса. Что, кажется, перебор

Как вы делаете выбор? Склоняюсь к первому варианту, тк коротко и ясно. Какие у него недостатки?

А с каких пор RunBase не в моде? Он был не в моде в AX2012, но в D365 его вернули в "моду" и даже официально рассказали, как его расширять. По тексту задачи - типичный RunBase
Давайте разберем предложенные Вами способы:
1. Отличный вариант, но с ограничением - что код будет находиться на форме и хотя тема "клиент-сервер" из D365 исключена, но расширять класс (на будущее) гораздо проще, чем форму. Но опять-таки... RunBase, к примеру, грид не поддерживает (для этого нужно создавать отдельную форму). Поэтому в каких-то случаях и форма "хороша". Также данный способ предполагает выполнение действия только с исходной формы (условно - веб-сервис это действие не выполнит)
2. Тоже самое, что и п.1, но с возможностью вынести логику в класс; не рисовать свою форму, а программно добавить поля в диалог (с ограничениями на возможности - типа без грида и т.д.). Плюс тут добавляется возможность выполнить код логики в отдельной сессии, что ускоряет его выполнение. Данный вариант хорош для действия, которое может быть вызвано потом отдельно из кода (как говорит выше - например, из веб-сервиса).
3. 4 класса - это не перебор, а заготовка к расширению. Т.е. если Вы пишете код, который потом будет находиться в модели, на которую будут ссылаться и делать к Вашему коду расширение - то 4 класса - это самое то. п.1 тут категорически не подойдет, а п.2 - "фифти-фифти" - тут смотреть надо. С технической же т.з. разницы в выполнении SysOperation и RunBase - нет. Это еще в AX 2012 RunBase не умел запускать код в отдельной сессии. А сейчас - умеет.

Поэтому тут, чтобы выбрать способ - нужно решить:
1. Будет ли эта логика как-то расширяться? Если да, то лучше п.2
2. Будет ли необходимо логику вызывать как-то программно? Если да, то лучше п.2
3. Нужен ли грид на форме-диалоге или же еще какие-то "сложные" контролы, которые не умеет добавлять RunBase? Если да, то лучше п.1.
4. Нужно ли программировать с учетом того, что к Вашей модели будут делать расширение? Если да, то п.3, причем если на форме будут "сложные" контролы - то тогда есть смысл делать еще и свою отдельную форму.

Конкретно к Вашей задаче - я бы сделал либо п.1, либо п.2. По привычке - сделал бы п.2. Но в принципе можно обойтись и п.1 (если строк не безумное количество и перебор строк занимает "адекватное" время и его не нужно выносить в отдельную процедуру). Но по времени разработки - добавить строчки в метод dialog несколько быстрее, чем рисовать дизайн формы

[Lankey]

Спасибо большое.
А есть какая-то официальная статья насчет реабилитации RunBаse в D365? Про раширение статью нашла.

Про вариант(1) не уверена,что поняла, почему я не могу вызвать класс с формы? Вы имеете в ввиду, что я могу, но просто смысла нет? (Тк создавать класс имело бы смысл раньше, тк он на сервере бы исполнялся, а сейчас, тк о том, гдле исполняется класс не имеет смысла думать, то можно логику и на форме оставить). Вы сразу пишете про то, что в классе проще логику расширять.
Поэтому, кажется, что имеет смысле именно сделать форму и из нее вызывать класс? Таким образом, если нужно расширить UI - добавляем элементы интерфейса в форму, а если надо расширить код(или его откуда-то еще вызвать), то раширяем класс. Или я Вас как-то неправльно поняла?

[sukhanchik]

Цитата:

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

Спасибо большое.
А есть какая-то официальная статья насчет реабилитации RunBаse в D365? Про раширение статью нашла.

Не... ну тут Вы рассуждаете без учета маркетинговой политики Microsoft. Сказав "А" никто никогда не скажет, что это "А" было неверно. Просто скажут такое "Б", из которого будет логически следовать, что "А" - неверно.

Если какая-то технология / функциональность признается устаревшей в текущей версии - то это автоматически означает, что она вырезается из следующей версии.
Если она не вырезается, то она как минимум останавливается в развитии.

Примеры: AIF в 2012 (был вырезан в D365FO), старый конфигуратор продукции, который существовал до AX 2012; в AX2012 был признан устаревшим и в D365FO его вырезали. Модуль "Основные средства Рус" (RAsset*) в D365FO по сути остановили в развитии в угоду развития модуля "Основные средства" (Asset*)

В случае с RunBase что произошло:
1. Его не вырезали
2. К нему сделали возможность загрузки файла (новая возможность по сравнению с AX2012)
3. Его "научили" выполнять метод run() в отдельной сессии, как раньше умела только SysOperation-технология
4. Про него написали в документации (вот уж прямой индикатор, что им продолжают активно пользоваться) - как расширять (Вы сами нашли статью)

Цитата:

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

Про вариант(1) не уверена,что поняла, почему я не могу вызвать класс с формы?

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

Начнём с простого. Чтобы выполнить задачу Вам по варианту 1 нужно либо создать форму и в ней написать логику, либо создать форму и класс, причем форма будет лишь промежуточным объектом для вызова класса.
Чтобы выполнить задачу Вам по варианту 2 - форму создавать не требуется (в той постановке, которую Вы привели). Это как минимум будет быстрее с т.з. разработки. Ну и с т.з. дальнейшего развития - развивать класс или класс + форму - всё таки разные вещи. Проще один объект развивать.

Про клиент-сервер забываем - да, в D365FO это неактуально.
Однако, класс можно отнаследовать; его можно включить в какое-нибудь пакетное задание (это конечно общий подход, а не конкретно к Вашей задаче); к любому методу класса можно обратиться "извне" из другого класса.
Форма не наследуется; в пакетное задание не включается, а вызов методов из формы усложнен тем, что синтаксический контроль названий методов для классов применяется автоматически - а для формы - нет. Т.е. (условно) создав метод на форме с названием "ХХХ" и вызвав из класса метод "YYY" - Вы никогда не получите ошибку компиляции из-за названия метода. А вот в случае с классом - получите

Т.е. общий вывод такой - вариант 2 просто быстрее в разработке и проще поддерживается (до определенного уровня конечно). А так конечно - любой способ приводит к результату

[LETTO]

Ну и еще капельку вдогонку.
RunBase простой и понятный каждому разработчику фреймворк.
А теперь представьте, что все разработчики начнут делать как вы - клепать свои классы и формы, каждый по своему паттерну.
Правило едино - для всех операций используйте RunBase по максимуму. Стандартно, просто, проверено временем, легко читаемо
Так что RunBase однозначно. SysOperationFramework - (мне кажется) лучше использовать для более "тяжелых" задач, нежели простое обновление данных на форме.

[pitersky]

Кмк тут какое-то недопонимание
Если создать менюайтем и выложить его на форму, то однозначно нужен будет и связанный класс, ибо запускаемый объект - одно из свойств менюайтема. А уж если есть класс, то он и будет RunBase (хотя если строк много, то наверное всё-таки лучше RunBaseBatch).
Если же без класса, сугубо на форме - то можно просто кнопку (Button) сделать и писать код непосредственно внутри clicked-метода этой кнопки. Никакого менюйтема тут не надо. Но могут быть проблемы с настройкой прав и масштабируемостью обработки (например, если надо будет запускать НЕ из формы, а из главного меню).
Так что лучше не полениться и сделать всё через класс.

P.S. Насчёт реабилитации RunBase. На моём первом проекте по 365 у нас был небольшой вводный тренинг. И вот на нём было озвучено, что RunBase снова назначен любимой женой и больше не является сугубо историческим фреймворком. Как я понимаю, это следствие использования SysOperation индусами в разработке в 2012 - микрософт на это посмотрел и сказал "ну вас нафиг, лучше по-старому работайте"))))

[Lankey]

Цитата:

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

Не... ну тут Вы рассуждаете без учета маркетинговой политики Microsoft. ...

Спасибо огромное, что все так доступно объяснили!

[sukhanchik]

Цитата:

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

Кмк тут какое-то недопонимание
Если создать менюайтем и выложить его на форму, то однозначно нужен будет и связанный класс, ибо запускаемый объект - одно из свойств менюайтема.

Менюайтем может же ссылаться не только на класс. Более того - если посмотреть формы типа "Drop box dialog", то там как раз пункт меню ссылается на форму, которая открывается, "пристёгнутой" к кнопке этого пункта меню. А таких мест в системе вполне себе хватает - и это одно из "направлений" дизайна интерфейса. Также пункт меню далеко не всегда обязан ссылаться на класс или форму. Есть еще другим типы (SSRS-отчеты, Info / Form Part-ы)

[Владимир Максимов]

Цитата:

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

3) SysOperationFramework - будет 4 класса. Что, кажется, перебор

Основное время разработчик тратит вовсе не на написание чего-то нового, а на анализ ранее написанного. Поэтому тот факт, что для чего-то нового надо много написать - вообще не аргумент. При реализации того же RunBase количество кода будет сопоставимо. Просто в рамках одного класса

Т.е. с точки зрения реализации, RunBase ничем не отличается от SysOperation. Варианты равнозначные. Тут нет каких-то аргументов, которые могли бы позволить сделать однозначный выбор в пользу использования того или другого. Вопрос привычки и личных предпочтений

PS: С моей точки зрения, SysOperation так и не удалось полноценно интегрировать в среду X++. Со всех сторон торчат разные "костыли". При этом еще и исполняемый код может зависеть от способа инициализации экземпляра класса, что вообще полная дичь. Но, тем не менее...

[pitersky]

Цитата:

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

Менюайтем может же ссылаться не только на класс

Та я знаю
Я имел в виду, что любой менюайтем должен быть привязан к какому-то объекту в системе. Класс, форма, отчёт - хоть что-то, но должно быть. А дальше уже идём по простейшему пути - привязываем класс с диалогом внутри