Runbase vs SysOperation

[trud]

Цитата:

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

а runbase разве не был проклят с появлением ангела sysoperation?

Проклят кем?
Идея sysoperation конечно изначальна была хороша, но никто не стал ее развивать. Т.е. сейчас RunBase это единственный способ писать расширяемые классы(с PU22 даже обещают через CoC). Расширения DataContract недоступны. Плюс иногда нужны доп. возможности, к примеру внутри класса управлять задачами, создавая подзадачи

[wojzeh]

Цитата:

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

Проклят кем?
Идея sysoperation конечно изначальна была хороша, но никто не стал ее развивать. Т.е. сейчас RunBase это единственный способ писать расширяемые классы(с PU22 даже обещают через CoC). Расширения DataContract недоступны. Плюс иногда нужны доп. возможности, к примеру внутри класса управлять задачами, создавая подзадачи

спасибо! не знал про это.

и что, в этой связи в d365 всё переделано взад на runbase?

[EVGL]

Цитата:

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

Расширения DataContract недоступны.

Анонсировано, что добавят.

[wojzeh]

Цитата:

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

Анонсировано, что добавят.

и опять выпустят фетву против runbase? нам-то чо делать: крестик снимать или...?

[gl00mie]

Мне кажется, подобно тому, как начинающие разработчики в прежних версиях упускали, где (на сервере или на клиенте) в какой момент времени будет выполняться тот или иной метод их наследника 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 в этом плане как-то больше дисциплинирует что ли.

[trud]

Цитата:

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

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

Вот это как раз непонятно. Вы же помните что unpack контракта у SysOperation происходит неявно в методе new? Т.е. вызывая SysOperation из кода вы вообще рискуете получить случайный набор параметров на входе.
Это на мой взгляд фундаментальный баг, о котором многие забывают(или не знают)
Например первая ссылка по запросу Post purchase order through code Ax2012 выдает следующий фрагмент кода(что отлично работало в 2009, когда класс был наследником от RunBase), который может прекратить работать в любом момент - из за того что юзер под которым это запускается может разнести PO из интерфейса со спец. параметрами(типа проверки кредитного лимита)

static void postPurchaseOrder(Args _args)
{
PurchTable purchTable = PurchTable::find();
PurchFormLetter purchFormLetter;

purchFormLetter = PurchFormLetter::construct(DocumentStatus::PurchaseOrder);
purchFormLetter.update(purchTable, , systemDateGet(), PurchUpdate::All);
}

[belugin]

Цитата:

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

Вот это как раз непонятно. Вы же помните что unpack контракта у SysOperation происходит неявно в методе new?

В методе new какого класса он происходит?
Контракт распаковывает контроллер. Который это делает в методе unpack.

Контракт - это такой же класс как и все, просто размеченный атрибутами.

[trud]

Цитата:

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

В методе new какого класса он происходит?
Контракт распаковывает контроллер. Который это делает в методе unpack.

ну да, в контроллере. Для PurchFormLetter это происходит неявно, в методе construct. причем в методе getDataContractObject
Хотя может это и кривизна конкретной реализации PurchFormLetter, но недавно мы много дней потеряли на поиски этой баги, когда у некоторых пользователей подставлялись старые значения при запуске разноски из кода
Я что-то подумал что это баг всего фрамеворка, но возможно стоит еще поизучать вопрос

[user_ax]

Цитата:

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

и опять выпустят фетву против runbase? нам-то чо делать: крестик снимать или...?

Не думаю, что до этого дойдет.
Расширение контракт классов - хорошее прекимущество, особенно когда закроют полностью app suite.
А то приходится такой велосипед городить чтобы добавить новые атрибуты в sys operation, просто капец.

Не думаю, опять же, что будут хаять опять runBase, если его так прокачали, как описали выше ( новая сессия, что несомненно круто!)