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

[mazzy]

в прошлой ветке я не получил ответ на свой вопрос
Как правильно выполнять unit-тестирования методов с параметрами по умолчанию на ваш взгляд?

но зато получилось сформулировать коренное отличие продуктов dynamics от традиционных средств разработки:

часть кода закрыта от изменения.

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

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

в MS CRM это система extensions. к подобной системе идет и Аксапта, кстати.

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


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

= в аксапте этот метод находится в слое sys. его сигнатуру нельзя менять
= в навике, насколько я помню, этот метод находится в закрытом codeunit'е
= в MS CRM - не знаю. но подозреваю, что расширение доступно только через extension

можно взять любой другой метод для примера.

[jopagames]

Дык, правильный ответ уже написан в самом вопросе.

Цитата:

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

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

Всё остальные способы - от лукавого
Обсуждение "полупиратских методов", насколько я помню, на этом форуме не приветствуется.

Другое дело, что иногда действительно ВОТ НУЖНО бывает создать в таблице 17 поле с номером 25 (ну, или удалить поле 24)
И хрен какая партнёрская лицензия (даже самая дорогая) даёт это сделать в этой таблице и в этом диапазоне.

ЗЫ: Но, вообще, основное в этом вопросе - открыть объект.
Т.е. всё же превратить его в текст, изменить, перекомпилировать и закатать обратно.
Таких способов есть несколько.

Будем обсуждать их здесь, Сергей?

[mazzy]

Цитата:

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

Будем обсуждать их здесь, Сергей?

А других способов совсем нет?

Если так, то пока достаточно констатации - только открыть. возможно применив reverse engineering.

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

[ax_mct]

Цитата:

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

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

Как минимум реализовать поддержку Interceptor and DI паттернов. Понять что мир программирования уже ушел далеко от классического ООП. И то классическое и святое ООП несовместимо с потребностями возникающими при создании расширений. Даже если приукрасить это прямоугольное OOП с помощью делегатов и подписки на события. Не та гибкость.

Interceptor pattern - это перехват методов позволяющий полностью их заменить.
https://en.wikipedia.org/wiki/Interceptor_pattern
http://docs.oracle.com/javaee/6/tutorial/doc/gkedm.html
http://stackoverflow.com/questions/1...ors-in-java-ee

DI - Dependency injection - это подход позволяющий встраиватьcя.
https://en.wikipedia.org/wiki/Dependency_injection
https://ru.wikipedia.org/wiki/%D0%92...81%D1%82%D0%B8

P.S. Справедливости ради в том или ином виде это есть в .NET в отдельных технологиях и библиотеках, но я не критикую MS в "отсталости", а говорю о реальной доступности применения как инструмента в конкретных наших по сути фреймворках. Когда инструментарий не соответствует потребностям.

[mazzy]

Цитата:

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

Как минимум реализовать поддержку Interceptor and DI паттернов. Понять что мир программирования уже ушел далеко от классического ООП. И то классическое и святое ООП несовместимо с потребностями возникающими при создании расширений. Даже если приукрасить это прямоугольное OOП с помощью делегатов и подписки на события.

Да, согласен - лучше быть богатым и здоровым, чем бедным и больным.

А как это эффективно и правильно сделать в существующем инструментарии?
И с существующим унаследованным кодом?

Цитата:

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

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

[belugin]

Что приходит на ум:

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

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

3. Грязные трюки (например рефлекшн для доступа к приватным методам, Moles) - Плюсы - больше возможностей чем 1. меньше кода чем в 2.. Минусы - сломается при апгрейде.

Вообще говоря, вся штука в том, чтобы вендор мог выделить такие интерфейсы которые:
1) Были бы достаточны для расширяющих
2) Сам вендор имел практическую возможность их не ломать.

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

Вопрос в том, чтобы отделить одно от другого.

Интересен также подход в опенсурс проектах - большинство софта пишут используя API но если надо чего-то еще, то можно предложить патч (насколько я знаю, даже MS патчил линукс, чтобы поддержать Hyper-V), если патч будет хорошим (по стандартам кодировния, документированным) то есть вероятность что его вольют в версию продукта.

[Sancho]

Цитата:

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

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

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

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

о!
ну и галочку в настройке "погодная скидка включена" по умолчанию - нет.
вот теперь да. как-то так.

[macklakov]

Цитата:

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

с ошибками, потому что сварганена на скорую руку.
не оттестирована на пельмешках в зной и семечках при штормовом ветре.

Что-то я не понял откуда это вытекает. Почему кастомный функционал обязательно на скорую руку и с ошибками?
P.S. идея метеорологической скидки/наценки, кстати, довольно интересная.

[belugin]

Цитата:

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

т.е. после всего стандарта одной строкой делаем вызов собственной функциональности.

Судя по вопросу Маззи, его больше интересует вопрос, как протащить туда свои параметры, учитывая что стандартный функционал уже передает примитивы, а не расширяемый объект-критерий.

[belugin]

Цитата:

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

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

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

Может быть из-за того, что менее оправданно дорого разрабатывать, если пользователей меньше

[mazzy]

Цитата:

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

Судя по вопросу Маззи, его больше интересует вопрос, как протащить туда свои параметры, учитывая что стандартный функционал уже передает примитивы, а не расширяемый объект-критерий.

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

[Артем Enot Грунин]

В случае с CRM дело обстоит сильно иначе. У нас нет внутреннего языка, или возможности править поведение системы, как таковое. Все что у нас есть, с точки зрения серверной логики - это плагины-обработчики событий системы. Технически, мы можем перехватить попытку чтения цены продукта и заменить выходное значение в своей логике, но на практике так не делается. Системные механизмы используют множество согласованных обработчиков, логика которых не документирована. На практике, если не подходит стандарт - делаешь рядом что-то свое. Победить и изменить - как правило, себе дороже. Но это в общих чертах, конечно. Бывают случаи проще, там можно доработать стандарт, если можно на него опираться, а не менять в корне.

[mazzy]

Цитата:

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

с точки зрения серверной логики - это плагины-обработчики событий системы.

event'ы?

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

тогда можно жить и вести разработку и в закрытой системе. так?

[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]

Цитата:

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

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

Цитата:

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

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

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

Вендор не просто меняет способ разработки по техническим причинам в D365FO, он тупо закрывает разработку функциональности вообще со стороны партнеров и клиентов. Всякие точки расширения и события - это пластмассовая косточка с клубничным вкусом. Пососать.

Событий и подписок - недостаточно.
Нужна возможность замены любых классов и методов целиком. Через конфигурационные файлы. Но это будет тот же overlayering по своей сути.