Вот мы и нашли этих 43 AX7 клиентов? Или это не AX7/D365?

[AlexSD]

Цитата:

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

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

А что нужно сделать что бы код с нулевым оверлеингом перевести на екстеншины?
Я полагаю, что ничего. Что там требуется переводить то? Все и так уже переведено.

ЗЫ. У меня есть опыт апргейда на 7-ку ISV (Demand Forecasting) с минимальным использованием стандартных таблиц и форм.И тулза - есть. Называется LCS.

[macklakov]

Цитата:

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

И интересно - что ему в этих случаях отвечают

Ну, в принципе, они стараются. Но в нашем регионе у них ресурсов не хватает пока что. Когда с emergency на первую линию поддержки попадаешь, им долго приходится объяснять что такое AX и что да, их контора действительно такое продает, это входит в линейку dynamics. Потом они посреди ночи ищут инжинера по всем миру. Находят. Инжинер читает описание ошибки, делает озадаченное лицо и говорит:"у нас в CRM склада нет". В конце концов вопрос решается, но в процессе бывает весело.
Но несмотря на накладки система работает. Баги расследуются, выпускаются фиксы. И вот когда фикс выпущен, его нужно как можно быстрее накатить всем клиентам, прежде чем пользователи столкнулись с проблемой. Похоже что изоляция между ядром и isv как раз для этого и вводится, чтобы фиксить ядро без необходимости merge с кастомизациями.
Как оно будет работать и будет ли работать вообще. Но процесс движется именно в этом направлении.

[trud]

Цитата:

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

А что нужно сделать что бы код с нулевым оверлеингом перевести на екстеншины?
Я полагаю, что ничего. Что там требуется переводить то? Все и так уже переведено.

Хм, LCS насколько мне известно экстеншены не создает(или уже создает?)

самый простой пример - поля на таблице. т.е. у вас есть новое поле "A" на CustTable лежащее в кастомизации этой таблицы, вы решаете сделать по модному..

создаете новую extension модель, далее вам надо в ней создать новый объект - extension для custTable, удалить поле из CustTable, добавить его в новый extension.
как только вы сделаете это "бонусом" получите неработоспособность тулзов в Visual Studio таких как обновить дата ентити по таблице.
далее если те кто установят ваше решение кодируют используя кастомизацию в AppSuite и захотят заюзать ваши поля, тут их тоже ждет сюрприз, так как поля собственно будут недоступны из AppSuite

или есть новый метод на классе - тут вообще переделка на экстеншены может быть невозможна если внутри него вы обращаетесь к private переменным

[Vadik]

Цитата:

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

далее если те кто установят ваше решение кодируют используя кастомизацию в AppSuite и захотят заюзать ваши поля

не по фэншую же

[skuull]

Цитата:

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

самый простой пример - поля на таблице. т.е. у вас есть новое поле "A" на CustTable лежащее в кастомизации этой таблицы, вы решаете сделать по модному..

Это не очень похоже на "нулевой оверлей", может раскроите ваше понимание этого словосочетания перед тем как мы продолжим дискусию ?

Цитата:

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

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

Если вы уже стоите на шатком пути оверлеинга App Suite, такие мелочи вас не должны останавливать. Создается третья модель, котороя ссылаеться на экстеншен и предастваляет доступ к полям, а App Suite ссылаеться на нее. Все легко и немного извращенно

[trud]

Цитата:

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

Это не очень похоже на "нулевой оверлей", может раскроите ваше понимание этого словосочетания перед тем как мы продолжим дискусию ?
:

в терминах 2012 - все ваши объекты содержатся только в вашем слое(не являются перекрытиями в sys). например новые поля в sys таблицах или методы классов. в рамках 2012 это позволяло обновляться на новые версии(CU) без мержинга кода

Цитата:

Создается третья модель, котороя ссылаеться на экстеншен и предастваляет доступ к полям, а App Suite ссылаеться на нее.

Ну как бы да, такой подход безусловно "упрощает и ускоряет" работу. Да и заказчик несомненно порадуется более большим счетам за услуги разработчика.

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

идеальным вариантом конечно было бы сделать возможности изменения теми которые сейчас есть в экстеншенах(т.е. возможность менять меню, форм, каких-то св-в без перекрытия базового кода) + предложить разработчику решать - хочет ли он помещать код в отдельную DLL(в этом случае компилятор уже должен следить чтобы не было обращений к приватным переменным и прочему) или вместе с основной. зачем они сделали 2 разных по сути формата файлов изменений (кастомизацию и экстеншн) это не очень понятно
несомненный негатив от экстеншенов в том виде как они сейчас есть - это то что это другой объект в AOT с произвольным названием и визуально их наличие реализовано слабо - т.е. раньше хотя бы все эвенты было видно в AOT, теперь можно подписаться на метод, это вообще никак визуально будет не видно
как разбираться в таком коде - особенно если он изначально разрабатывался не вами - не очень понятно, на мой взгляд время проведенное за анализом будет поболее чем время за обновлением на очередной CU

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

[fed]

В дискуссии trud vs skuull, меня больше всего удивляет, что никто даже не рассматривает вариант "Сделать все на overlay, а если Микрософт будет докапываться - предложить им оплатить дополнительные затраты на использование extensions"

[EVGL]

Цитата:

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

В дискуссии trud vs skuull, меня больше всего удивляет, что никто даже не рассматривает вариант "Сделать все на overlay, а если Микрософт будет докапываться - предложить им оплатить дополнительные затраты на использование extensions"

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

[fed]

Цитата:

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

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

Ну сейчас же обновляемся - просто время на мердж уходит (в пределах одного релиза - весьма умеренное - типа часиков 10 на все про все).

[trud]

Цитата:

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

"Сделать все на overlay

Ну речь немного не про это. Т.е. сейчас существует 2 типа моделей - вы выбираете этот тип при создании модели экстеншн модель и модель кастомизации.
физически это означает будет ваш код лежать в отдельной папке или подпапки у какой-то модели

если выбрана экстеншн модель - в ней можно создавать только экстеншн, в модели кастомизации можно создавать как экстеншены так и кастомизации

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

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

автоматом это решение мигрирует на D365, где тоже не будет оверлея - мигрирует оно в модель кастомизации

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

[fed]

Мне как раз просто интересно - а зачем вообще использовать extensions, если они явно повышают трудозатраты на разработку, а трудозатраты на апгрейд, в типичном случае, снижают несильно ? Ну то есть - я могу представить какого-то нишевого ISV, который, например, написал приблуду для печати бар-кодов, интегрировал ее только через extensions и счастлив. Там этот подход вполне жизнеспособен.
Но вот когда я гляжу на типичный внедренческий проект, я понимаю что на одних extensions его в принципе не сделаешь. Более того - есть ощущение что процентов 70 типичных доработок будет уходить в overlay независимо от того, насколько сильно вам хочется использовать extensions. И вот отсюда и вопрос - а стоит ли городить огород с extensions на типичном проекте, если мы точно знаем что апгрейдить и мерджить приложение все равно придется (из за тех самых 70% типичных доработок ушедших в overlay...)?

[trud]

Extension для элементов или extension модели? Это же разные вещи
Extension для элементов позволяет менять меньше системного кода – тот же меню айтем добавить в меню, или в формах можно обойтись без перекрытия. Т.е. цель использования – сократить изменения в коде, чтобы легче фиксы ставить. Это вполне такой рабочий инструмент если использовать без фанатизма
extension модели – это другое. Зачем его используют на проектах я не понимаю, пример использования я видел и это было мягко говоря не очень. На вопрос – а собственно нафига, следовал стандартный ответ – ну мы же AX7, тут надо Extension

[skuull]

Цитата:

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

В дискуссии trud vs skuull, меня больше всего удивляет, что никто даже не рассматривает вариант "Сделать все на overlay, а если Микрософт будет докапываться - предложить им оплатить дополнительные затраты на использование extensions"

Вариант рассматриваетсяю Но вместе с ним рассматривается вариант что возьмут модель и залочат для оверлея, как случилось с некоторыми Будет и смешно и грустно.

[AlexSD]

Цитата:

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

Хм, LCS насколько мне известно экстеншены не создает(или уже создает?)

LCS сама екстеншины не создает. Но, мы говорим о ISV с нулевым оверлеингом. Екстеншины для ISV с нулевым оверлеем не особо нужны.

Цитата:

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

самый простой пример - поля на таблице. т.е. у вас есть новое поле "A" на CustTable лежащее в кастомизации этой таблицы, вы решаете сделать по модному..

создаете новую extension модель,

С полями, можно обойтись без екстеншина. По старинке, как сделали с некоторыми полями в локализации для 2012. Все кастомные поля в отдельную таблицу, связь по RecId c базовой таблицей. Такой подход продолжает работать для D365. Единственно, что придется в этом случае екстендить - это формы, что бы вывести свои поля на стандартные формы.

По поводу новой модели. Зачем создавать новую модель для екстеншинов? У ISV с нулевым оверлеем есть своя модель, добавляйте екстеншины в эту же модель с ISV.

[trud]

Цитата:

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

Но, мы говорим о ISV с нулевым оверлеингом. Екстеншины для ISV с нулевым оверлеем не особо нужны.
С полями, можно обойтись без екстеншина.
По поводу новой модели. Зачем создавать новую модель для екстеншинов? У ISV с нулевым оверлеем есть своя модель, добавляйте екстеншины в эту же модель с ISV.

я вот как раз полностью с этим согласен. мы вот создаём все изменения в модели с типом кастомизация, в которой и создаем экстеншены и прочее.

разговор собственно начался с фразы ниже, и обсуждению зачем это нужно.

Цитата:

МС поставил перед ними срок 12 месяцев чтобы переделать свой ISV на 100% экстеншен

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

Цитата:

Cоздается третья модель, котороя ссылаеться на экстеншен и предастваляет доступ к полям, а App Suite ссылаеться на нее

[AlexSD]

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

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

[skuull]

Цитата:

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

т.е. я под этой фразой понимаю требование переноса решения в модель с типом Extension

Наличие типов у моделей вообще и типа "Extension" в частности для меня лично являеться больлшим открытием
Под этой фразой я имел в виду отсутствие Overlayering. Не забываем о том что ребята продают ISV и как только клиент захочет купить два разных ISV с оверлеингом App suite кто интересно будет ему их сводить? Вернее свести то не проблема, в 12 сводили и норм, но радужная картина апп стора и деплойментов 1 кнопкой из LCS рушиться к чертям

Цитата:

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

но народ кстати на яммере довольно активно этим занимает, некоторые используя подход описанный skuull, насоздавали уже по 10 моделей, зачем то они ж это делают

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

[trud]

как раз для AppStore и нужны extension модели. тип модели задается при создании

[skuull]

Цитата:

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

как раз для AppStore и нужны extension модели. тип модели задается при создании

Это не тип модели это пакет модели. Вы выбираете создавать новый пакет или использовать существующий. Пакет компилируется в dll, модель же несет характер метаданных, как и проект и нужна только для того чтобы логически группировать ваш код. Преимущество своего пакета в том что вы его можете поставлять отдельно, если же ваша модель принадлежит пакету App Suite вы деплоите одну огромную dll которая содержит 2 строчки вашего кода, пускай даже в вашей модели, и еще большую часть АХ.

[trud]

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