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