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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 20.07.2024, 10:15   #1  
Lankey is offline
Lankey
Участник
 
127 / 28 (1) +++
Регистрация: 19.05.2020
Разница между runBase, sysOperationFramework и (формой+класс)
Добрый день
У меня вопрос на понимание
D365
Есть у меня форма в шапке с Заголовком и внизу с линиями в гриде (как на форме закупок). По нажатию кнопки на форме пользователю должен быть показан диалог, где он вводит дату и интервал(int). По закрытию диалога поле Дата на линиях грида долно пересчитаться по формуле: дата текущей линии = дата предыдущей линни+интервал (есть нормер линии,поэтому поянтно, как считать)

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

Как вы делаете выбор? Склоняюсь к первому варианту, тк коротко и ясно. Какие у него недостатки?
Старый 20.07.2024, 12:20   #2  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,312 / 3547 (125) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от 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 несколько быстрее, чем рисовать дизайн формы
__________________
Возможно сделать все. Вопрос времени

Последний раз редактировалось sukhanchik; 20.07.2024 в 12:23.
За это сообщение автора поблагодарили: macklakov (18).
Старый 21.07.2024, 10:43   #3  
Lankey is offline
Lankey
Участник
 
127 / 28 (1) +++
Регистрация: 19.05.2020
Спасибо большое.
А есть какая-то официальная статья насчет реабилитации RunBаse в D365? Про раширение статью нашла.

Про вариант(1) не уверена,что поняла, почему я не могу вызвать класс с формы? Вы имеете в ввиду, что я могу, но просто смысла нет? (Тк создавать класс имело бы смысл раньше, тк он на сервере бы исполнялся, а сейчас, тк о том, гдле исполняется класс не имеет смысла думать, то можно логику и на форме оставить). Вы сразу пишете про то, что в классе проще логику расширять.
Поэтому, кажется, что имеет смысле именно сделать форму и из нее вызывать класс? Таким образом, если нужно расширить UI - добавляем элементы интерфейса в форму, а если надо расширить код(или его откуда-то еще вызвать), то раширяем класс. Или я Вас как-то неправльно поняла?
Старый 21.07.2024, 11:48   #4  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,312 / 3547 (125) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от 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 просто быстрее в разработке и проще поддерживается (до определенного уровня конечно). А так конечно - любой способ приводит к результату
__________________
Возможно сделать все. Вопрос времени

Последний раз редактировалось sukhanchik; 21.07.2024 в 11:51.
За это сообщение автора поблагодарили: Lankey (1).
Старый 21.07.2024, 11:54   #5  
LETTO is offline
LETTO
Участник
 
318 / 64 (3) ++++
Регистрация: 14.07.2022
Ну и еще капельку вдогонку.
RunBase простой и понятный каждому разработчику фреймворк.
А теперь представьте, что все разработчики начнут делать как вы - клепать свои классы и формы, каждый по своему паттерну.
Правило едино - для всех операций используйте RunBase по максимуму. Стандартно, просто, проверено временем, легко читаемо
Так что RunBase однозначно. SysOperationFramework - (мне кажется) лучше использовать для более "тяжелых" задач, нежели простое обновление данных на форме.
Старый 21.07.2024, 12:08   #6  
pitersky is offline
pitersky
северный Будда
Аватар для pitersky
Ex AND Project
Соотечественники
 
1,510 / 435 (18) +++++++
Регистрация: 26.09.2007
Адрес: Солнечная система
Кмк тут какое-то недопонимание
Если создать менюайтем и выложить его на форму, то однозначно нужен будет и связанный класс, ибо запускаемый объект - одно из свойств менюайтема. А уж если есть класс, то он и будет RunBase (хотя если строк много, то наверное всё-таки лучше RunBaseBatch).
Если же без класса, сугубо на форме - то можно просто кнопку (Button) сделать и писать код непосредственно внутри clicked-метода этой кнопки. Никакого менюйтема тут не надо. Но могут быть проблемы с настройкой прав и масштабируемостью обработки (например, если надо будет запускать НЕ из формы, а из главного меню).
Так что лучше не полениться и сделать всё через класс.

P.S. Насчёт реабилитации RunBase. На моём первом проекте по 365 у нас был небольшой вводный тренинг. И вот на нём было озвучено, что RunBase снова назначен любимой женой и больше не является сугубо историческим фреймворком. Как я понимаю, это следствие использования SysOperation индусами в разработке в 2012 - микрософт на это посмотрел и сказал "ну вас нафиг, лучше по-старому работайте"))))
__________________
С уважением,
Вячеслав
Старый 21.07.2024, 12:44   #7  
Lankey is offline
Lankey
Участник
 
127 / 28 (1) +++
Регистрация: 19.05.2020
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Не... ну тут Вы рассуждаете без учета маркетинговой политики Microsoft. ...
Спасибо огромное, что все так доступно объяснили!
Старый 22.07.2024, 07:49   #8  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,312 / 3547 (125) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от pitersky Посмотреть сообщение
Кмк тут какое-то недопонимание
Если создать менюайтем и выложить его на форму, то однозначно нужен будет и связанный класс, ибо запускаемый объект - одно из свойств менюайтема.
Менюайтем может же ссылаться не только на класс. Более того - если посмотреть формы типа "Drop box dialog", то там как раз пункт меню ссылается на форму, которая открывается, "пристёгнутой" к кнопке этого пункта меню. А таких мест в системе вполне себе хватает - и это одно из "направлений" дизайна интерфейса. Также пункт меню далеко не всегда обязан ссылаться на класс или форму. Есть еще другим типы (SSRS-отчеты, Info / Form Part-ы)
__________________
Возможно сделать все. Вопрос времени
Старый 22.07.2024, 09:56   #9  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,692 / 1195 (43) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от Lankey Посмотреть сообщение
3) SysOperationFramework - будет 4 класса. Что, кажется, перебор
Основное время разработчик тратит вовсе не на написание чего-то нового, а на анализ ранее написанного. Поэтому тот факт, что для чего-то нового надо много написать - вообще не аргумент. При реализации того же RunBase количество кода будет сопоставимо. Просто в рамках одного класса

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

PS: С моей точки зрения, SysOperation так и не удалось полноценно интегрировать в среду X++. Со всех сторон торчат разные "костыли". При этом еще и исполняемый код может зависеть от способа инициализации экземпляра класса, что вообще полная дичь. Но, тем не менее...
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 06.08.2024, 19:42   #10  
pitersky is offline
pitersky
северный Будда
Аватар для pitersky
Ex AND Project
Соотечественники
 
1,510 / 435 (18) +++++++
Регистрация: 26.09.2007
Адрес: Солнечная система
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Менюайтем может же ссылаться не только на класс
Та я знаю
Я имел в виду, что любой менюайтем должен быть привязан к какому-то объекту в системе. Класс, форма, отчёт - хоть что-то, но должно быть. А дальше уже идём по простейшему пути - привязываем класс с диалогом внутри
__________________
С уважением,
Вячеслав
Теги
d365, runbase, sysoperation framework, в365

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
RunBase vs SysOperationFramework для Excel отчета kitty DAX: Программирование 28 01.02.2016 19:46
Класс для преобразования значений между различными значимыми типами gl00mie DAX: Программирование 0 02.09.2011 11:17
пропадают связи между классами наследниками RunBase ice DAX: Администрирование 18 02.09.2010 13:14
Разница между запросами Rect DAX: Программирование 13 05.12.2006 12:44
Класс RunBase SergS DAX: База знаний и проекты 0 19.06.2002 18:07
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

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

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

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