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

[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, такую форму не полез бы со своими таблицами. Прилепил бы поля на новую форму и повесил бы ее куда-нибудь на кнопку.