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

[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 это убрали, а сейчас они заново по сути изобретают тоже самое.

[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 ссылаеться на нее

[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 строчки вашего кода, пускай даже в вашей модели, и еще большую часть АХ.

[macklakov]

Цитата:

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

Все кастомные поля в отдельную таблицу, связь по RecId c базовой таблицей. Такой подход продолжает работать для D365.

А потом приходится устраивать пляски с бубном вокруг SQL чтобы он отрабатывал запросы в 30 таблиц в более-менее вменяемое время. И это без XDS, которую любой консультант спомощью галочки может активировать. С другой стороны, это извечная дилемма мира AX:"как совместить удобство Office с мощью SAP"

[AlexSD]

Цитата:

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

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

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

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

Короче, это не та причина, что бы перестать создавать свои таблицы.

[macklakov]

Цитата:

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

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

Почему же только для одной? И почему только одного ISV рассматриваем? Ну и все стандартные формы корежить не обязательно. Хватит и парочки чтобы пользователи взвыли.

Цитата:

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

Например, для тех форм, где уже есть 25-29 таблиц

Ну вот давай рассмотрим сценарий:
На стандартной форме 24 таблице в join.
Устанавливается 2 решения от 2-х разных ISV. Каждое из решений добавляет по 3 таблицы.
В очередно релизе MS решает накинуть еще несколько табличек. Часто для системных нужд. Рефакторинг, нормализация, шаблоны проектирования и все такое.
И не забываем что типичный консультант свято уверен что врубить флажок secure by legal entity в параметрах GAB логичное решение. Ведь это стандарт и в доках его рекомендуют использовать.
Так вот, сколько у нас в результате таблиц в запросе получится?
P.S. Нет, я согласен, что концепция красивая и в любом случае "все там будем", но есть у меня ощущение что граблей тут разбросано изрядно. Топтать и топтать.

[AlexSD]

Цитата:

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

Почему же только для одной? И почему только одного ISV рассматриваем?

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

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

В случае, когда на форме уже есть 24 таблицы, я бы, как вендор ISV, такую форму не полез бы со своими таблицами. Прилепил бы поля на новую форму и повесил бы ее куда-нибудь на кнопку.