D365: passing through public method by means of Pre- and Post-event handlers

[belugin]

Цитата:

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

каждом обновлении аудит изменений на их логическую уже совместимость.

*Теоретически* (то есть отвлекааясь от Аксапты данной нам в ощущениях) при создании расширения надо руководствоваться публичным контрактом метода включая побочные эффекты а не его исходным кодом (реализацией).

Контракт может быть описан как неформально (в XML документации) так и формально (например, набором тестов, Code Contracts).

Цитата:

Ничего страшного в подмене нет. Это даст больше управляемости и надежности. А проверять конфликты можно и компилятором.

Вопрос: чем тогда это отличается от оверлееринга только хуже?

Цитата:

Ничего страшного в подмене нет. Это даст больше управляемости и надежности. А проверять конфликты можно и компилятором.

Вопрос: чем тогда это отличается от оверлееринга только хуже?

[wojzeh]

Цитата:

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

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

вот это прямо золотые слова! это ж похоже на одного из трёх китов ООП!

[ax_mct]

Цитата:

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

*Теоретически* (то есть отвлекааясь от Аксапты данной нам в ощущениях) при создании расширения надо руководствоваться публичным контрактом метода включая побочные эффекты а не его исходным кодом (реализацией).

Не вопрос когда содержание метода это одна атомарная и самодостаточная фунция.
Чтение из файла например. А вот создание строки заказа уже по сути интерфейс к процессу. А там где процесс без исходного кода никак.

Цитата:

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

Вопрос: чем тогда это отличается от оверлееринга только хуже?

Ничем. Да, хуже. От того что пытаются уйти от ошибок компиляции сам по себе оверлееринг никуда не исчезает. Его просто не видно. А со старым оверлеерингом - было видно.

Ведь какая цель у нас программистов в большинстве случаев? Именно что логический оверлей какого-то процесса, просто потому что это в сути стоящих перед нами задач. Мало того что процессную систему прибили ООП так теперь еще и запретили менять процессы.

Без возможности оверлееринга/подмены мы не можем вносить изменения в процесс, мы можем только подключать свои собственные независимые процессы.
Это может быть нормально само по себе, но это совершенно недостаточно для (1 закона Кибернетики) тех требований которые предьявляет наш типичный клиент.

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

Вот EVGL хорошо иллюстрирует.

Цитата:

Это все только слова и теоретические рассуждения. На практике все происходит с точностью до наоборот, и я могу это доказать на цифрах. При переходе с 7.1 на 7.2 наше приложение согласно отчету анализа обновления было затронуто 119 (прописью: сто девятнадцать) уничтоженными полями или таблицами, и это только data dictionary. Весь код, который это использовал - расширения, перекрытия, классы с бизнес-логикой - может идти лесом. Т.е. мастера по redesign / reengineering в Microsoft плевали на доработки и партнерские решения. Они ломали и будут ломать, с корнем удалять, менять внутреннюю логику. При этом самое худшее, что может случиться, это формально компилируемый код расширений, который просто перестал вызываться или работать из-за изменения порядка исполнения объектов.

P.S. Извиняюсь что не в теме про Погоду тьфу про аномимных оверлейщиков.

[belugin]

Цитата:

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

Не вопрос когда содержание метода это одна атомарная и самодостаточная фунция.
Чтение из файла например.

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

Цитата:

А вот создание строки заказа уже по сути интерфейс к процессу. А там где процесс без исходного кода никак.

Все есть интерес к процессу (хотя бы небольшого) и тем не менее у всего есть публичный интерфейс и реализация.

Цитата:

Ничем. Да, хуже. От того что пытаются уйти от ошибок компиляции сам по себе оверлееринг никуда не исчезает. Его просто не видно. А со старым оверлеерингом - было видно.

То есть в подменяющих экстеншенах смысла нет вообще.

Цитата:

Ведь какая цель у нас программистов в большинстве случаев? Именно что логический оверлей какого-то процесса, просто потому что это в сути стоящих перед нами задач.

Это когда как, иногда расширение. Иногда надо написать новый код поверх существующих бизнес сущностей.

Цитата:

Без возможности оверлееринга/подмены мы не можем вносить изменения в процесс, мы можем только подключать свои собственные независимые процессы.

Это не всегда так. Можно например подменить стандартный класс своим в конструкте. То есть заменять куски проуессов там где это предусмотрено и понятно какой интерфейс у кусков.

Цитата:

Вот EVGL хорошо иллюстрирует.

EVGL я ответил.