D365FO: Организация разработки - слияние модификаций

[skuull]

Цитата:

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

Модели. Пакет (я правильно понимаю, что пакет = deployable package?) в себе может конечно содержать несколько моделей, но только если они не ссылаются друг на друга.

Вы уверенны что именно модели ссылаются на модели ? Т.е., по вашему, возможна ситуация когда у меня есть deployable package A с 2мя моделями: АА и АБ, где АА ссылаеться на AppSuite, а АБ - нет ?

[sukhanchik]

Цитата:

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

Вы уверенны что именно модели ссылаются на модели ? Т.е., по вашему, возможна ситуация когда у меня есть deployable package A с 2мя моделями: АА и АБ, где АА ссылаеться на AppSuite, а АБ - нет ?

Ээээ... Что-то Вы меня смутили )))
Ситуация. Имеем порядка 20 моделей, каждая из которых создавалась, как Create new package (выбирался этот режим в мастере при создании модели).
Эти модели могут ссылаться на разные модели, в т.ч. кто-то может ссылаться на AppSuite, а кто-то нет. Помимо AppSuite есть еще Directory, ContactPerson и еще куча мелких моделей, на которые уж точно не все модели ссылаются.
Кроме стандартных моделей они могут ссылаться друг на друга (циклические ссылки исключены). Т.о. у меня получилось 5 уровней пакетов. 1-й уровень - модели, ссылающиеся на стандартные модели, 2-й уровень - модели, ссылающиеся на стандартные модели и модели 1-го уровня; 3-й уровень - модели ссылающиеся на стандартные модели и модели 1-го и 2-го уровней и т.д. Само собой одна моя модель принадлежит какому-то одному уровню.

Так вот - при апгрейде кода с 7.2 PU10 на 8.0 PU15 была создана в облаке чистая среда (не проапгрейдена, а именно создана с нуля), в которой были только стандартные модели. На нее было последовательно залито 5 deployable package, каждый из которых соответствовал уровню пакета (а в пакете было само собой несколько моделей). Т.о. были залиты все 20 моделей.
Пакет (package) тут вообще ни причем. Ссылки идут на модели. И нельзя заливать пакет, в котором находятся модели, ссылающиеся друг на друга. А вот по уровням - пожалуйста. И совершенно без разницы - есть ли в где-то в одной модели ссылка на AppSuite или ее нет

[skuull]

Цитата:

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

Ээээ... Что-то Вы меня смутили )))
Ситуация. Имеем порядка 20 моделей, каждая из которых создавалась, как Create new package

Вот вы и ответили на мой вопрос. Вы создаете 1 пакет на 1 модель. Модели, насколько я понимаю, существуют только в дизайне и потом всё равно все билдится по-пакетно. Т.е. как писал выше belugin пакеты = модули которые ссылаются на что-то. В одном пакете (не deployable, это я не правильно спросил, просто пакете) может быть много моделей которые ни на что не ссылаются, посмотрите на AppSuite пакет, там много моделей.

Зачем я все это спрашиваю ? Просто МС активно на яммере пишет, что если вы не ISV то больше 1 пакета вам не надо. В вашем случае мне интересно что вы выиграли от этого? Ведь пакет с 3го уровня нельзя выдернуть и использовать отдельно без первого и второго уровня. Имея 20 меточных файлов можно попасть в ситуацию когда в каждом из них есть метка "Конь" и если вы решили переименовать ее в "Сфера" то придётся создавать 20 новых меток вместо одной.

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

[trud]

Цитата:

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

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

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

[sukhanchik]

Цитата:

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

Вот вы и ответили на мой вопрос. Вы создаете 1 пакет на 1 модель. Модели, насколько я понимаю, существуют только в дизайне и потом всё равно все билдится по-пакетно. Т.е. как писал выше belugin пакеты = модули которые ссылаются на что-то. В одном пакете (не deployable, это я не правильно спросил, просто пакете) может быть много моделей которые ни на что не ссылаются, посмотрите на AppSuite пакет, там много моделей.

Все понятно, большое спасибо.

Цитата:

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

Зачем я все это спрашиваю ? Просто МС активно на яммере пишет, что если вы не ISV то больше 1 пакета вам не надо. В вашем случае мне интересно что вы выиграли от этого? Ведь пакет с 3го уровня нельзя выдернуть и использовать отдельно без первого и второго уровня. Имея 20 меточных файлов можно попасть в ситуацию когда в каждом из них есть метка "Конь" и если вы решили переименовать ее в "Сфера" то придётся создавать 20 новых меток вместо одной.

В моем случае все просто. Как начали создавать пакеты, так и дальше продолжили не задумываясь о последствиях. Так что тут искать глубокого смысла не стоит, тем более, что яммер - штука в явном виде не сильно открытая и большими красными буквами в заголовке там не пишут, что требуется всего один пакет - надо быть достаточно активным читателем яммера ) (хотя я его и просматриваю периодически).
Но решение продолжить так работать в моем случае подкрепилось скоростью билда. Я вот смотрю на AppSuite (на папку в PackagesLocalDirectory) и пока не особо вижу большого количества там подпапок, да и dll-ка там получается одна на пакет и достаточно большая (интересно, долго ли она билдится?)


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

Цитата:

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

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

Это да, по сути получается как разработка на разных слоях. Но вот если у Вас был опыт разработки в одном пакете и разных моделях - то как сильно увеличилось время билда в таком режиме? В моем понимании - dll-ка должна создаваться одна на пакет, а не на модель в наших с Вами терминах.

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

Из плюсов моего подхода у меня пока выявился один (не считая скорости билда). Возможно есть еще (а также есть минусы), я просто не сравнивал свой подход с каким-либо другим.
Я делал импорт различных данных из Sharepoint и я смог разделить свой код на 2 части. Одну, которая подключается к Sharepoint, авторизуется и получает данные и вторую, которая эти данные обрабатывает. В результате я создал несколько моделей - одну для работы с Sharepoint и другие, которые ссылаются на эту модель (как будто у меня получилось мини-ISV-решение для импорта из Sharepoint).
Билд модели, которая связана с Sharepoint был усложнен наличием дополнительной dll-ки, написанной на C#. А билд моделей-обработчиков ничем не усложнен и выполняется быстро. В результате получилась ситуация "забилдил и забыл", что очень упрощает дальнейшую разработку в сторону Sharepoint-а

В общем - было бы интересно, с какими плюсами и минусами столкнулись те, кто пошел по пути одного пакета и нескольких моделей в одном пакете.