Как правильно вести разработку в условиях, когда часть кода закрыта от изменения - Sys-слой в аксапте, закрытые codeunit в навике, extensions в MS CRM

[fed]

Цитата:

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

что должен сделать вендор?
что может сделать партнер/заказчик своими силами?

Ну я бы сказал - вендор должен постоянно анализировать доработки на идущих проектах, которые были сделаны оверлеерингом. Контактировать с партнером, если смысл доработок не понятен. Реинженерить и дописывать свои собственные классы так чтобы в дальнейшем типичные доработки можно было бы делать без оверлееринга.
При таком раскладе - я могу представить что годков через 5 такой работы и вправду 85% типичных внедрений можно будет делать на чистых extensions.
Только зная микрософтовское отношение к инвестициям в реинженеринг и рефакторинг, я больше верю в давление на микрософт (чтобы не лочили) или к хакерским подходам (когда в режиме on-premise система работает не совсем так как микрософт планировал )

[mazzy]

уважаемые, навижиноводы, а в навике эвенты-события-триггераНаФункции есть? или что-то подобное?

[Sancho]

триггеры на таблице в целом, триггеры на каждом поле, триггеры на контролах формы.
нужны еще триггеры (счетчик запуска функции, например) - пишем сами внутри ф-ции

[mazzy]

Цитата:

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

пишем сами внутри ф-ции

а если функция внутри закрытого кодеюнита?

[Captain]

Цитата:

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

а если функция внутри закрытого кодеюнита?

С NAV 2015 и выше появились системные Events. Если Microsoft заявил их публичными, то почему нельзя ими пользоваться?. На 2017 вроде таких ~250.

https://community.dynamics.com/nav/b...l-about-events

[mazzy]

Цитата:

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

С NAV 2015 и выше появились системные Events. Если Microsoft заявил их публичными, то почему нельзя ими пользоваться?. На 2017 вроде таких ~250.

Спасибо.
Я не знаю можно или нельзя. Поэтому спрашиваю.

ух, ты:
Subscriber functions cannot access the sender and or access global variables.
https://msdn.microsoft.com/en-us/lib...v=nav.90).aspx


Set the Event property to Publisher. This makes the function an event publisher.
https://msdn.microsoft.com/en-us/lib...v=nav.90).aspx

т.е. опубликовать событие можно просто изменив свойство функции.
но при этом подписчики не получают доступ к паблишеру...

А в CRM также?
Тогда снова актуален вопрос:
Как правильно вести разработку в условиях, когда часть кода закрыта от изменения, а платформа предоставляет систему событий и подписок?

Поделитесь,
= какие приемы эффективной разработки вы используете?
= Какие плюсы и минусы у закрытого кода в вашей системе?
= Что на ваш взгляд должен сделать майкрософт, как поставщик продукта, чтобы разработка была эффективной?

[mazzy]

В Аксапте тоже есть события.
но я пока не видел ни одного использования.

в каких-то объектах стандартных событий много, в каких-то объектах (view) станадртных событий вообще нет. а в классах события похоже прописываются только руками

я правильно понимаю, что поставщик бизнес-логики должен продумать и опубликовать систему событий для каждого бизнес-объекта?

а как это сейчас происходит в Навике и в MS CRM?

[ax_mct]

Вот еще:
https://ievgensaxblog.wordpress.com/...ut-overlaying/

А вот это самое интересное
https://ievgensaxblog.wordpress.com/...ut-overlaying/

Цитата:

AX 7. How to override form data source field methods without overlaying.

[mazzy]

Цитата:

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

Вот еще:
https://ievgensaxblog.wordpress.com/...ut-overlaying/

А вот это самое интересное
https://ievgensaxblog.wordpress.com/...ut-overlaying/

спасибо, суть понятна.
немного напоминает технику программного переопределения методов в dialog().

sender.object(fieldNum(SalesLine, ItemId)).registerOverrideMethod(methodStr(FormDataObject, jumpRef),
            methodStr(SalesTableFormExtensionOverrides, itemId_OnJumpRef), overrides);

прикрутить делегатов и будет как у нормальных людей.

а другие способы есть?
можно ли как-то создать собственный event в объекте, который находится в закрытом участке?

[fed]

Цитата:

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

а другие способы есть?
можно ли как-то создать собственный event в объекте, который находится в закрытом участке?

Если задуматься, то ты спрашиваешь: "Есть ли универсальный способ использовать призвольный кусок кода в произвольной задаче?" То есть - все потеницальные способы, которые тут назвали или могут назвать, подходят только в том случае, если задача в понимании авторов куска и реальная прикладная задача отличаются несильно.
Так что вопрос не в методах кодинга, а в соответствии между реальностью и той версией реальности, которая содержалась в ТЗ на разработку неизменяемого куска кода. Если соответствие слишком слабо, никакие хитровывернутые фреймворки и механизмы расширения не помогут...

[belugin]

Цитата:

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

можно ли как-то создать собственный event в объекте, который находится в закрытом участке?

Мне кажется, закрытость кода противоречит возможности создания там event просто по определению.

Закрытость нужна для того, чтобы вендор знал, что не менять, чтобы не сломать расширения. Если расширятель может добавить любой интерфейс в любом месте, то, очевидно, вендор не знает что он не может менять.

[sukhanchik]

Цитата:

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

Мне кажется, закрытость кода противоречит возможности создания там eventHandler просто по определению.

Закрытость нужна для того, чтобы вендор знал, что не менять, чтобы не сломать расширения. Если расширятель может добавить любой интерфейс в любом месте, то, очевидно, вендор не знает что он не может менять.

Закрытость позволяет вендору скрывать свои ошибки и не делиться архитектурой системы с конкурентами. Все публикуемые косяки в АХ всегда публиковались на закрытом партнерском сайте, а никак не на support.microsoft.com, открытым для всех.
Т.е. скажем так - вендор в лице MS априори заинтересован в закрытом коде. Просто в силу общей политики MS.

Вот есть пример 1:
MS SQL Server
Я могу создать Database Trigger, который мне запретит допустим грохать вьюшки. Код SQL Server-а закрыт. Я даже вьюшку могу зашифровать и закрыть ее. Тем не менее - сей триггер - это в некотором смысле extension и eventHandler. Я сильно сомневаюсь, что MS сильно задумывается о том, каким синтаксисом T-SQL я это делал и вполне может чего-то поменять не задумываясь о том, что у меня сломается

Пример 2:
MS Office (Word/Excel) и VBA.
VBA - по своей сути - это и есть eventHandler-ы и extension-ы. Ну т.е. это не самостоятельный язык; люди покупающие офис в большинстве своем не стремятся писать много кода на VBA, но ... исходный код Word / Excel нам недоступен. Доступны только сигнатуры методов. Т.е. оттрассировать Word / Excel в их "sys-слое" нельзя.

[belugin]

Цитата:

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

Вот есть пример 1:
Я могу создать Database Trigger, который мне запретит допустим грохать вьюшки.

Это использование существующего event а.

Цитата:

Пример 2:
MS Office (Word/Excel) и VBA.
VBA - по своей сути - это и есть eventHandler-ы и extension-ы.

Это тоже использование существующего event а - вы не можете добавить в Word.Application новый эвент

[mazzy]

ребяты, страдания сюда: Клуб анонимных оверлейщиков

я знаю, что есть другие продукты.
вопрос что делать в данном конкретном раскладе в данных конкретных условиях.

Как вести разработку с минимальными в долгосрочной перспективе трудозатратами
в условиях, есть куча унаследованного кода И часть кода закрыта от изменения,
а платформа предоставляет систему событий и подписок?

[fed]

Цитата:

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

ребяты, страдания сюда: Клуб анонимных оверлейщиков

Дык ты сам спросил "что вендор должен делать"...

[mazzy]

Цитата:

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

Дык ты сам спросил "что вендор должен делать"...

извини, я конечно же неправильно сформулировал.
я хотел спросить что "вендор должен реализовать в коде", чтобы у всех было меньше трудозатрат.

[fed]

Ах да - еще неплохо было бы "Стену плача" (Aka Microsoft Connect) заменить на какое-то более структурированное средство. Чтобы там можно было бы и требования собирать, и вывешивать бета-версии спецификаций (по крайней мере - какую-то выжимку из них)и тд и тп.
Вообще - с переходом к модели подписки, плата за софт начинает становится все более похожей на налог. (Поскольку платишь ты не столько за готовый продукт, сколько за какие-то сервисы, которые в будущем будут как-то развиваться).
Ну и хочется напомнить об известном принципе "No taxation without representation". Если вендоры (не только микрософт) будут активно толкать пользователей в сторону модели подписки, очень вероятно что этих вендоров судебным образом продавят на какую-то модель участия пользовательской базы в принятии решений о том как собранные за подписку деньги потратить...

[sukhanchik]

Было бы хорошо отделить вариант CRM от вариант АХ.
В CRM исходный код закрыт. Поэтому разработчики могут только догадываться, как он работает.

Цитата:

Сообщение от Артем Enot Грунин

Системные механизмы используют множество согласованных обработчиков, логика которых не документирована. На практике, если не подходит стандарт - делаешь рядом что-то свое. Победить и изменить - как правило, себе дороже.

В ранних внедрениях АХ это было знакомо, когда внедренцы не зная стандартную функциональность - самостоятельно писали аналогичную функциональность под конкретного клиента.

В АХ исходный код открыт. Да, нельзя изменить сигнатуры методов, но как минимум код можно прочитать и понять, что он делает. Как максимум - можно его потрассировать на конкретной ситуации и выяснить - виноват алгоритм (ошибка в коде) или сам дурак - поставил галку "Нескладируемая" у группы моделей номенклатуры и думаешь - почему InventTrans не создается

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

В случае, когда доступ к коду закрыт вообще - подход Артема оправдан. Если доступ открыт - то можно его проанализировать и подумать, как исправлять. Где "врезаться".
Если код открыт, то можно создать какой-нибудь eventHandler на PriceDisc* классе и прикрутить туда метеорологический способ определения цены.
Если код закрыт - то самое простое - залезть в заказ и переопределить место, куда цена приходит уже рассчитанная.

[sukhanchik]

Ну т.е. получается - будет одна "большая дырка", через которую будут делать все .
Я конечно утрирую, но все определит количество доступных разработчику event-ов.
В рамках поставленной mazzy задачи - если будут event-ы на PriceDisc*-классах, то "врежемся" туда. Если будет event только на строке заказа при подстановке цены - то "врежемся" туда. Если оставят "дырку" только на этапе разноски заказа - то значит там будем менять цену.

Будет спрос на event что-нибудь типа "при старте системы", в который будет загружаться своя форма, свой код и дальше будет работать "свой extension". Который не будет мешать MS-у обновлять свой никем не используемый код ))))

Я шучу конечно, но общий смысл такой - если есть какой-то объект в системе, который все постоянно модифицируют, то после закрытия такого объекта - будет проще его вообще не трогать, а закодить копию (копию по сути) этого объекта "на стороне".

Ну т.е. есть к примеру, заказы на продажу. Их закрыли на изменение. Я пошел и добавил свой объект "акты оказанных услуг" . Естественно добавил туда только то, что мне надо. И пусть MS обновляет эти заказы...

[trud]

Цитата:

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

Ну т.е. есть к примеру, заказы на продажу. Их закрыли на изменение. Я пошел и добавил свой объект "акты оказанных услуг" . Естественно добавил туда только то, что мне надо. И пусть MS обновляет эти заказы...

А вот кстати вопрос - так можно с точки зрения лицензионных соглашений? т.е. можете ли вы продублировать функциональность системы поставив еще дополнительно у дублируемых меню айтемов(они же ваши, новые) более дешевый тип лицензии(например task вместо enterprise)