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

**mazzy** · 21.03.2017, 14:12

Цитата:

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

Всякие точки расширения и события - это пластмассовая косточка с клубничным вкусом. Пососать.

Ой, все. Страдать пожалуйста сюда: Клуб анонимных оверлейщиков

Цитата:

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

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

Возможно. Замечание принимается.
Уточню название темы:

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

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

ax_mct · 21.03.2017, 14:32

Цитата:

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

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

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

Каким бы нехорошим не был подход с рефлексией, но он заслуживает серьезного внимания.
https://ievgensaxblog.wordpress.com/...xtension-code/

X++:

using System.Reflection;
 
/// <summary>
/// Handles events raised by <c>SalesLineTypeEventHandler</c> class.
/// </summary>
public class SalesLineTypeEventHandler
{
    [PostHandlerFor(classStr(SalesLineType), methodStr(SalesLineType, insert))]
    public static void SalesLineType_Post_insert(XppPrePostArgs _args)
    {
        SalesLineType salesLineType = _args.getThis();
 
        var bindFlags = BindingFlags::Instance | BindingFlags::NonPublic;
 
        var field = salesLineType.GetType().GetField("salesLine", bindFlags);
 
        SalesLine salesLine = field.GetValue(salesLineType);
 
        if (salesLine)
        {
            salesLine.MyNewField = 42;
            salesLine.doUpdate();
        }
    }
}

Вендор же никому ничего не должен

**fed** · 21.03.2017, 14:34

Цитата:

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

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

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

)

ax_mct · 21.03.2017, 14:41

Вот еще:
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** · 21.03.2017, 14:43

Цитата:

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

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

Да, заслуживает.
Но рефлексия - это тут же уход в динамическое программирование взамен статической компиляции. Со всеми плюсами и минусами.

И соответствующими холиварами на эту тему )))

Цитата:

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

Вендор же никому ничего не должен

это тоже неправда )))
но должен он очень мало чего и мало кому. это так.

**mazzy** · 21.03.2017, 14:45

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

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

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

**fed** · 21.03.2017, 14:48

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

**fed** · 21.03.2017, 14:49

Цитата:

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

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

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

**mazzy** · 21.03.2017, 14:52

Цитата:

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

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

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

**mazzy** · 21.03.2017, 15:05

Цитата:

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

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

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

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

X++:

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

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

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

**sukhanchik** · 21.03.2017, 15:10

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

Цитата:

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

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

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

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

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

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

**fed** · 21.03.2017, 15:14

Цитата:

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

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

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

belugin · 21.03.2017, 15:28

Цитата:

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

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

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

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

**sukhanchik** · 21.03.2017, 15:42

Цитата:

Сообщение от 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-слое" нельзя.

**Артем Enot Грунин** · 21.03.2017, 15:48

По сути да, это эвент ресиверы. Есть воронка обработки события, куда можно встроиться на разных этапах, в том числе и до вызова системной логики. Приблизительно 99% событий доступны для обработки, но мы не можем отключить обработчики от MS. Максимум "исправить" то что они сделали. Так работать можно, модель рабочая. Но, как я говорил, в каких то случаях, проще написать свое

belugin · 21.03.2017, 16:17

Цитата:

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

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

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

Цитата:

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

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

**sukhanchik** · 21.03.2017, 16:43

Перечитал еще раз сообщения, подумал.
Если код закрыт, то действительно, новый event на PriceDisc*-классах я не создам. Но я могу увидеть исходный код, то я могу посмотреть его и надеяться на то, что там мне MS оставит event, в который я смогу встроиться.
Если нет исходного кода, то я уже буду полагаться только на свое наитие (и, возможно, документацию, которая может и не помочь). А мое наитие может меня обмануть

**sukhanchik** · 21.03.2017, 17:03

Ну т.е. получается - будет одна "большая дырка", через которую будут делать все

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

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

))))

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

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

. Естественно добавил туда только то, что мне надо. И пусть MS обновляет эти заказы...

trud · 21.03.2017, 17:16

Цитата:

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

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

. Естественно добавил туда только то, что мне надо. И пусть MS обновляет эти заказы...

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

**sukhanchik** · 21.03.2017, 17:43

Цитата:

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

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

Ну тут-то как раз как мне кажется просто. Если я дублирую функциональность, то ... я ее в программном плане не дублирую, а реализую лишь уже то, что реализовано в узком смысле, то, что нужно мне. Всяко функциональность заказов на продажу будет больше по объему функциональности моего "акта об оказанных услугах". Я еще могу "облениться" и просто нарисовать свой интерфейс, который даже напрямую в General Journal* не будет лазить, а просто будет создавать ЖГК.
Т.е. быстро, просто и под меня. С т.з. программного кода - там даже и не будет пахнуть идеей заказов на продажу. С т.з. философии системы / Best Practice - это неверно. Но... проблему с обновлениями я решил. А с лицензией - еще надо как-то доказать, что мои Task-и "заслуживают" Enterprise

. Конечно, если я явно буду использовать ЖГК - то наверное это будет явно и видно. А вот если я задействую лишь архитектуру АХ... то на архитектуре как бы не стоит тип пользователя

В общем - MS-у мне кажется придется прописывать какие-то более четкие правила использования типов лицензий (используешь в коде класc DimensionStorage - все, значит Enterprise. Пишешь ручками джойны - Task)

))))))))