Цитата:
Сообщение от
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 несколько быстрее, чем рисовать дизайн формы
