|
09.07.2017, 18:29 | #1 |
Участник
|
Цитата:
Партнер теперь может ДОБАВИТЬ какую-то логику в выполнение salesLine.update(), без overlayering. Для того чтобы это сделать, ему не нужно никого спрашивать, если Вы об этом.. |
|
09.07.2017, 19:52 | #2 |
Banned
|
Цитата:
Сообщение от kashperuk
Раньше в salesLine.update(), к примеру, super() не вызывался. Вместо этого вызывался salesLineType.update(), который внутри делал record.doUpdate()
После рефакторинга super() будет вызываться в salesLine.update(), а весь код вокруг него который был в salesLineType вынесен в различные методы. Тем самым достигается несколько вещей: - Теперь можно будет подписаться на вызов onInserted, onUpdated, onUpdating, etc. на SalesLine - раньше это было невозможно, так как event тригеррится в super() - Теперь можно будет с помощью CoC или pre/post-method handlers добавлять требуемую партнерскую логику, которая должна выполняться во время обновления строки заказа. Цитата:
При наличии ЛЮБЫХ кастомизаций обновлять автоматически что-бы то ни было в Production уровня ERP - неприемлимый риск для бизнеса. Даже если называть это hot fix. Поэтому все эти фичи расширения - бессмысленны. Нельзя расширять при seemless updates/ continuous update approach for the whole system including functionality. А если можно в staging вначале то слоеный overlayering намного надежнее. И необходимости в переходе на extensions в случае тестирования на staging - нет. То есть прямо говорю о полной бессмысленности перехода с overlayering на extensions при seemless updates. Эти дырки - для никого. |
|
|
За это сообщение автора поблагодарили: macklakov (1). |
10.07.2017, 11:38 | #3 |
Участник
|
Цитата:
Сообщение от 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. Эти дырки - для никого. |
|
|
За это сообщение автора поблагодарили: Vadik (1). |
10.07.2017, 11:52 | #4 |
Banned
|
Цитата:
Тема давняя. До тех пор, пока разработка Microsoft будет придерживать свои автоматизированные тесты у себя и только рассказывать без примеров, как удобно и просто их строить, в 90% случаев партнеры свои тесты писать даже для ISV модулей не будут . |
|
|
За это сообщение автора поблагодарили: Bobkov (1). |
10.07.2017, 11:57 | #5 |
Moderator
|
Цитата:
Сообщение от EVGL
Нет, конечно. Даже Microsoft Services не пишет автоматизированные тесты, это удорожило бы разработку вдвое.
Тема давняя. До тех пор, пока разработка Microsoft будет придерживать свои автоматизированные тесты у себя и только рассказывать без примеров, как удобно и просто их строить, в 90% случаев партнеры свои тесты писать даже для ISV модулей не будут . |
|
10.07.2017, 12:53 | #6 |
Участник
|
Тесты, закрытие модели для изменений, отсутствие доступа на рабочую и т.п. - все это можно пережить старым партнерам. Новым партнерам - может, даже, все нравится. Маленькая проблема - клиент, который сравнит стоимость внедрения и поддержки и пройдет мимо. И весь dynamic подход, за что покупали Аксапту, пойдет лесом.
__________________
Ivanhoe as is.. |
|
|
За это сообщение автора поблагодарили: Logger (3). |
10.07.2017, 15:34 | #7 |
Участник
|
|
|
10.07.2017, 15:40 | #8 |
Участник
|
Цитата:
Если бы мы поставляли тесты, их бы нужно было обновлять при внесении партнером изменений. У нас больше 100 тыщ тестов - сомневаюсь, что кто-то бы в них ковырялся. |
|
10.07.2017, 16:01 | #9 |
Участник
|
В Dynamics AX 100500 таблиц, классов, форм и т.д. Никто во "всех" объектах не ковыряется. Включайе в стадартную поставку функциональные тесты.
|
|
|
За это сообщение автора поблагодарили: macklakov (1). |
10.07.2017, 17:49 | #10 |
Banned
|
Цитата:
Сообщение от skuull
Т.е. формально гвоздь в кришку гроба этих внедрений уже забит, никакого отношение к оверлеингу это не имеет, вот и обсуждать нечего.
А с практической точки зрения граждане бангладеша сидящие на клиенте\партнере не сильно отличаються от своих сограждан в МС и также успешно развалят ваш InventDim и в extension модели, и в старой 12ке и в 9ке. Цитата:
Отказ от оверлеинга затем чтобы было проще - тестировать некую 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. Последний раз редактировалось ax_mct; 10.07.2017 в 18:11. |
|
10.07.2017, 18:24 | #11 |
Участник
|
|
|
10.07.2017, 18:54 | #12 |
Banned
|
|
|
Теги |
#многоходовочка, #стокгольмскийсиндром, extensions, overlayering, все пропало, титаник задраен |
|
|