Runbase vs SysOperation

[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, если его так прокачали, как описали выше ( новая сессия, что несомненно круто!)