Клуб анонимных оверлейщиков

[ax_mct]

Цитата:

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

Нет. Банально идет речь о том, что на методы SalesTableType.update() и SalesLineType.update() повесили атрибут [Hookable] или отрефакторили там, чтобы можно было вклиниваться в исполнение кода.

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

Но зачем? Затем чтобы можно было автоматически и без спроса менять этот "базовый" код в Production.
То есть, код SalesLineType.update() может меняться автоматически и без спроса в Production. Это так или нет? В этом вопрос.

[Vadik]

Нет. Не может

[ax_mct]

Цитата:

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

Нет. Не может

А зачем тогда уникальный механизм cлоев заменяется на точки расширения?
Не менять sys* обьекты - это понятно, но речь то идет к примеру о salesLineType и прочих.

В случае использования слоев (overlayering) я cразу могу видеть конфликт визуально, а в случае прицепления - все очень и очень неочевидно.

Если мне не разрешают overlayering для salesLineType то единственное обьяснение для меня что они хотят делать с этими классами что хотят и когда хотят. А иначе смысла в запрещении overlayering - просто нет.

Цитата:

Application Suite Hard Seal is a game changer. It unlocks a continuous update approach for the whole system including functionality and platform.

То есть тот же salesLineType.update() может меняться автоматически вендором в Production.
Откуда уверенность что "Нет. Не может"?
Потому что не могут взрослые люди играть со спичками на пороховом заводе?

http://www.intergen.co.nz/blog/Dynam...-mean-for-you/

[kashperuk]

Цитата:

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

Но зачем? Затем чтобы можно было автоматически и без спроса менять этот "базовый" код в Production.
То есть, код SalesLineType.update() может меняться автоматически и без спроса в Production. Это так или нет? В этом вопрос.

Production или не-Production тут не причем.

Партнер теперь может ДОБАВИТЬ какую-то логику в выполнение salesLine.update(), без overlayering.

Для того чтобы это сделать, ему не нужно никого спрашивать, если Вы об этом..

[ax_mct]

Цитата:

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

Раньше в salesLine.update(), к примеру, super() не вызывался. Вместо этого вызывался salesLineType.update(), который внутри делал record.doUpdate()

После рефакторинга super() будет вызываться в salesLine.update(), а весь код вокруг него который был в salesLineType вынесен в различные методы.

Тем самым достигается несколько вещей:
- Теперь можно будет подписаться на вызов onInserted, onUpdated, onUpdating, etc. на SalesLine - раньше это было невозможно, так как event тригеррится в super()
- Теперь можно будет с помощью CoC или pre/post-method handlers добавлять требуемую партнерскую логику, которая должна выполняться во время обновления строки заказа.

Цитата:

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

Production или не-Production тут не причем.

Партнер теперь может ДОБАВИТЬ какую-то логику в выполнение salesLine.update(), без overlayering.

Для того чтобы это сделать, ему не нужно никого спрашивать, если Вы об этом..

Спасибо. Production или не-Production как раз очень причем.
При наличии ЛЮБЫХ кастомизаций обновлять автоматически что-бы то ни было в Production уровня ERP - неприемлимый риск для бизнеса. Даже если называть это hot fix.

Поэтому все эти фичи расширения - бессмысленны. Нельзя расширять при seemless updates/
continuous update approach for the whole system including functionality.

А если можно в staging вначале то слоеный overlayering намного надежнее. И необходимости в переходе на extensions в случае тестирования на staging - нет.

То есть прямо говорю о полной бессмысленности перехода с overlayering на extensions при seemless updates. Эти дырки - для никого.

[kashperuk]

Цитата:

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

Спасибо. Production или не-Production как раз очень причем.
При наличии ЛЮБЫХ кастомизаций обновлять автоматически что-бы то ни было в Production уровня ERP - неприемлимый риск для бизнеса. Даже если называть это hot fix.

Поэтому все эти фичи расширения - бессмысленны. Нельзя расширять при seemless updates/
continuous update approach for the whole system including functionality.

А если можно в staging вначале то слоеный overlayering намного надежнее. И необходимости в переходе на extensions в случае тестирования на staging - нет.

То есть прямо говорю о полной бессмысленности перехода с overlayering на extensions при seemless updates. Эти дырки - для никого.

А если они перед этим будут прогонять все ваши автоматизированные тесты? У Вас есть тесты?

[EVGL]

Цитата:

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

А если они перед этим будут прогонять все ваши автоматизированные тесты? У Вас есть тесты?

Нет, конечно. Даже Microsoft Services не пишет автоматизированные тесты, это удорожило бы разработку вдвое.

Тема давняя. До тех пор, пока разработка Microsoft будет придерживать свои автоматизированные тесты у себя и только рассказывать без примеров, как удобно и просто их строить, в 90% случаев партнеры свои тесты писать даже для ISV модулей не будут .

[fed]

Цитата:

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

Нет, конечно. Даже Microsoft Services не пишет автоматизированные тесты, это удорожило бы разработку вдвое.

Тема давняя. До тех пор, пока разработка Microsoft будет придерживать свои автоматизированные тесты у себя и только рассказывать без примеров, как удобно и просто их строить, в 90% случаев партнеры свои тесты писать даже для ISV модулей не будут .

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

[Ivanhoe]

Цитата:

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

А если они перед этим будут прогонять все ваши автоматизированные тесты? У Вас есть тесты?

Тесты, закрытие модели для изменений, отсутствие доступа на рабочую и т.п. - все это можно пережить старым партнерам. Новым партнерам - может, даже, все нравится. Маленькая проблема - клиент, который сравнит стоимость внедрения и поддержки и пройдет мимо. И весь dynamic подход, за что покупали Аксапту, пойдет лесом.

[Morpheus]

Цитата:

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

А если они перед этим будут прогонять все ваши автоматизированные тесты? У Вас есть тесты?

Разве Microsoft поставляет вместе с D365 функионалые тесты к стандартной функциональности?

[kashperuk]

Цитата:

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

Разве Microsoft поставляет вместе с D365 функионалые тесты к стандартной функциональности?

Нет. Но партнеру то надо не столько стандартную функциональность тестировать, сколько свои изменения.

Если бы мы поставляли тесты, их бы нужно было обновлять при внесении партнером изменений. У нас больше 100 тыщ тестов - сомневаюсь, что кто-то бы в них ковырялся.

[Morpheus]

Цитата:

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

Нет. Но партнеру то надо не столько стандартную функциональность тестировать, сколько свои изменения.

Если бы мы поставляли тесты, их бы нужно было обновлять при внесении партнером изменений. У нас больше 100 тыщ тестов - сомневаюсь, что кто-то бы в них ковырялся.

В Dynamics AX 100500 таблиц, классов, форм и т.д. Никто во "всех" объектах не ковыряется. Включайе в стадартную поставку функциональные тесты.

[ax_mct]

Цитата:

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

Т.е. формально гвоздь в кришку гроба этих внедрений уже забит, никакого отношение к оверлеингу это не имеет, вот и обсуждать нечего.
А с практической точки зрения граждане бангладеша сидящие на клиенте\партнере не сильно отличаються от своих сограждан в МС и также успешно развалят ваш InventDim и в extension модели, и в старой 12ке и в 9ке.

Цитата:

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

А если они перед этим будут прогонять все ваши автоматизированные тесты? У Вас есть тесты?

Это лаборатория сумашедшего ученого.

Отказ от оверлеинга затем чтобы было проще

- тестировать некую DLL в базовой версии приложения,

- предоставлять дырки и крючки чтобы было можно менять это приложение,

- чтобы затем эту DLL заливать без какого-либо тестирования в живую измененную версию.

При этом всем отказ от визуального средства обнаружения конфликтов кода чтобы граждане бангладеша могли не волноваться.

Microsoft будет прогонять автоматизированные тесты с проектов внедрений и от ISV в многочисленных версиях? Это какой Microsoft имеется в виду?

https://community.dynamics.com/ax/b/...sibility-plans

Цитата:

There are also costs required for manually applying hot fixes. The ability to seamlessly apply hot fixes in a binary format is something we’re striving for in the future.
There’s also the ‘version hell’ that partners constantly battle. Reducing the size of the support matrix driven by combinations of Microsoft product versions and partner solution versions would be a significant benefit. Supporting many code branches is a large tax on any engineering team.

P.S. Виноват, выше отсылка про поддержание множества версий систем - это Dave про партнеров и для партнеров. Значит все-таки Microsoft будет иметь все эти измененные через дырки и хуки приложения и сам тестировать свои планируемые изменения в базовом коде для каждого клиентского приложения. Не так и плохо. Молодцы, заботятся.

[trud]

Цитата:

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

Это лаборатория сумашедшего ученого.

Скоро..

[ax_mct]

Цитата:

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

Скоро..

Очень возможно что с таким MCSD я бы чувствовал себя более комфортно.
Он не сумашедший по крайней мере. Ни при чем тут люди от сохи.