Цитата:
Сообщение от
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-а
В общем - было бы интересно, с какими плюсами и минусами столкнулись те, кто пошел по пути одного пакета и нескольких моделей в одном пакете.