![]() |
#1 |
Участник
|
Разница между runBase, sysOperationFramework и (формой+класс)
Добрый день
У меня вопрос на понимание D365 Есть у меня форма в шапке с Заголовком и внизу с линиями в гриде (как на форме закупок). По нажатию кнопки на форме пользователю должен быть показан диалог, где он вводит дату и интервал(int). По закрытию диалога поле Дата на линиях грида долно пересчитаться по формуле: дата текущей линии = дата предыдущей линни+интервал (есть нормер линии,поэтому поянтно, как считать) Я могу 1) Cделать MenuItem, что открывает форму-диалог и в closeOk запустит класс , что обновит записи, и вызовет reread/refresh формы-родителя 2) RunBase, что сделает в одном классе и диалог и обновление. Но RunBase не в моде в D365 . 3) SysOperationFramework - будет 4 класса. Что, кажется, перебор Как вы делаете выбор? Склоняюсь к первому варианту, тк коротко и ясно. Какие у него недостатки? |
|
![]() |
#2 |
Administrator
|
Цитата:
Сообщение от Lankey
![]() Добрый день
У меня вопрос на понимание D365 Есть у меня форма в шапке с Заголовком и внизу с линиями в гриде (как на форме закупок). По нажатию кнопки на форме пользователю должен быть показан диалог, где он вводит дату и интервал(int). По закрытию диалога поле Дата на линиях грида долно пересчитаться по формуле: дата текущей линии = дата предыдущей линни+интервал (есть нормер линии,поэтому поянтно, как считать) Я могу 1) Cделать MenuItem, что открывает форму-диалог и в closeOk запустит класс , что обновит записи, и вызовет reread/refresh формы-родителя 2) RunBase, что сделает в одном классе и диалог и обновление. Но RunBase не в моде в D365 . 3) SysOperationFramework - будет 4 класса. Что, кажется, перебор Как вы делаете выбор? Склоняюсь к первому варианту, тк коротко и ясно. Какие у него недостатки? Давайте разберем предложенные Вами способы: 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). |
![]() |
#3 |
Участник
|
Спасибо большое.
А есть какая-то официальная статья насчет реабилитации RunBаse в D365? Про раширение статью нашла. Про вариант(1) не уверена,что поняла, почему я не могу вызвать класс с формы? Вы имеете в ввиду, что я могу, но просто смысла нет? (Тк создавать класс имело бы смысл раньше, тк он на сервере бы исполнялся, а сейчас, тк о том, гдле исполняется класс не имеет смысла думать, то можно логику и на форме оставить). Вы сразу пишете про то, что в классе проще логику расширять. Поэтому, кажется, что имеет смысле именно сделать форму и из нее вызывать класс? Таким образом, если нужно расширить UI - добавляем элементы интерфейса в форму, а если надо расширить код(или его откуда-то еще вызвать), то раширяем класс. Или я Вас как-то неправльно поняла? |
|
![]() |
#4 |
Administrator
|
Цитата:
Сообщение от Lankey
![]() Спасибо большое.
А есть какая-то официальная статья насчет реабилитации RunBаse в D365? Про раширение статью нашла. Если какая-то технология / функциональность признается устаревшей в текущей версии - то это автоматически означает, что она вырезается из следующей версии. Если она не вырезается, то она как минимум останавливается в развитии. Примеры: AIF в 2012 (был вырезан в D365FO), старый конфигуратор продукции, который существовал до AX 2012; в AX2012 был признан устаревшим и в D365FO его вырезали. Модуль "Основные средства Рус" (RAsset*) в D365FO по сути остановили в развитии в угоду развития модуля "Основные средства" (Asset*) В случае с RunBase что произошло: 1. Его не вырезали 2. К нему сделали возможность загрузки файла (новая возможность по сравнению с AX2012) 3. Его "научили" выполнять метод run() в отдельной сессии, как раньше умела только SysOperation-технология 4. Про него написали в документации (вот уж прямой индикатор, что им продолжают активно пользоваться) - как расширять (Вы сами нашли статью) Цитата:
- выполнить первичную разработку - много позже расширить эту функциональность (если потребуется). Начнём с простого. Чтобы выполнить задачу Вам по варианту 1 нужно либо создать форму и в ней написать логику, либо создать форму и класс, причем форма будет лишь промежуточным объектом для вызова класса. Чтобы выполнить задачу Вам по варианту 2 - форму создавать не требуется (в той постановке, которую Вы привели). Это как минимум будет быстрее с т.з. разработки. Ну и с т.з. дальнейшего развития - развивать класс или класс + форму - всё таки разные вещи. Проще один объект развивать. Про клиент-сервер забываем - да, в D365FO это неактуально. Однако, класс можно отнаследовать; его можно включить в какое-нибудь пакетное задание (это конечно общий подход, а не конкретно к Вашей задаче); к любому методу класса можно обратиться "извне" из другого класса. Форма не наследуется; в пакетное задание не включается, а вызов методов из формы усложнен тем, что синтаксический контроль названий методов для классов применяется автоматически - а для формы - нет. Т.е. (условно) создав метод на форме с названием "ХХХ" и вызвав из класса метод "YYY" - Вы никогда не получите ошибку компиляции из-за названия метода. А вот в случае с классом - получите Т.е. общий вывод такой - вариант 2 просто быстрее в разработке и проще поддерживается (до определенного уровня конечно). А так конечно - любой способ приводит к результату
__________________
Возможно сделать все. Вопрос времени Последний раз редактировалось sukhanchik; 21.07.2024 в 11:51. |
|
|
За это сообщение автора поблагодарили: Lankey (1). |
![]() |
#5 |
Участник
|
Ну и еще капельку вдогонку.
RunBase простой и понятный каждому разработчику фреймворк. А теперь представьте, что все разработчики начнут делать как вы - клепать свои классы и формы, каждый по своему паттерну. Правило едино - для всех операций используйте RunBase по максимуму. Стандартно, просто, проверено временем, легко читаемо Так что RunBase однозначно. SysOperationFramework - (мне кажется) лучше использовать для более "тяжелых" задач, нежели простое обновление данных на форме. |
|
![]() |
#6 |
северный Будда
|
Кмк тут какое-то недопонимание
Если создать менюайтем и выложить его на форму, то однозначно нужен будет и связанный класс, ибо запускаемый объект - одно из свойств менюайтема. А уж если есть класс, то он и будет RunBase (хотя если строк много, то наверное всё-таки лучше RunBaseBatch). Если же без класса, сугубо на форме - то можно просто кнопку (Button) сделать и писать код непосредственно внутри clicked-метода этой кнопки. Никакого менюйтема тут не надо. Но могут быть проблемы с настройкой прав и масштабируемостью обработки (например, если надо будет запускать НЕ из формы, а из главного меню). Так что лучше не полениться и сделать всё через класс. P.S. Насчёт реабилитации RunBase. На моём первом проекте по 365 у нас был небольшой вводный тренинг. И вот на нём было озвучено, что RunBase снова назначен любимой женой и больше не является сугубо историческим фреймворком. Как я понимаю, это следствие использования SysOperation индусами в разработке в 2012 - микрософт на это посмотрел и сказал "ну вас нафиг, лучше по-старому работайте"))))
__________________
С уважением, Вячеслав |
|
![]() |
#7 |
Участник
|
|
|
![]() |
#8 |
Administrator
|
Менюайтем может же ссылаться не только на класс. Более того - если посмотреть формы типа "Drop box dialog", то там как раз пункт меню ссылается на форму, которая открывается, "пристёгнутой" к кнопке этого пункта меню. А таких мест в системе вполне себе хватает - и это одно из "направлений" дизайна интерфейса. Также пункт меню далеко не всегда обязан ссылаться на класс или форму. Есть еще другим типы (SSRS-отчеты, Info / Form Part-ы)
__________________
Возможно сделать все. Вопрос времени |
|
![]() |
#9 |
Участник
|
Основное время разработчик тратит вовсе не на написание чего-то нового, а на анализ ранее написанного. Поэтому тот факт, что для чего-то нового надо много написать - вообще не аргумент. При реализации того же RunBase количество кода будет сопоставимо. Просто в рамках одного класса
Т.е. с точки зрения реализации, RunBase ничем не отличается от SysOperation. Варианты равнозначные. Тут нет каких-то аргументов, которые могли бы позволить сделать однозначный выбор в пользу использования того или другого. Вопрос привычки и личных предпочтений PS: С моей точки зрения, SysOperation так и не удалось полноценно интегрировать в среду X++. Со всех сторон торчат разные "костыли". При этом еще и исполняемый код может зависеть от способа инициализации экземпляра класса, что вообще полная дичь. Но, тем не менее...
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
![]() |
#10 |
северный Будда
|
Та я знаю
![]() ![]() Я имел в виду, что любой менюайтем должен быть привязан к какому-то объекту в системе. Класс, форма, отчёт - хоть что-то, но должно быть. А дальше уже идём по простейшему пути - привязываем класс с диалогом внутри
__________________
С уважением, Вячеслав |
|