Расширенная поддержка модульности при проектировании приложений

[bratchikov]

Что подразумевается под модульностью в данном контексте

Для начала разберёмся что подразумевается под модульностью в приложениях.
Варианты модульности в Run-Time (архитектура во время исполнения программы):

Варианты модульности в Design-Time (архитектура исходных кодов на этапе проектирования):

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

• Возможность собрать конечное приложение только из необходимых модулей
• Возможность небольшого переопределения готового базового модуля
• Относительно независимая разработка модулей

Проблемы при проектировании с модульным подходом

Flexberry предлагает несколько возможностей для организации модульного проектирования:

• Наследование классов
• external-классы из соседних проектов

Тем не менее, данные возможности несут в себе дополнительные издержки. Например, в случае использования external-классов из соседних проектов мы получаем жёсткую связку множества проектов без возможности упраления версионированием и обновлением по частям.
Наследование тоже имеет ряд неприятных моментов, несмотря на логичное применение при расширении атрибутивного состава:

• Наследование по умолчанию ложится в логику Table per class (TPC), что для модульного подхода с переопределением не всегда подходит. Каждый переопределённый вариант получает новую таблицу в БД - это обычно лишнее в данном контексте.
• Опираясь на подход TPC в связях между классами, которые имеют иерархию наследования мы получаем проблему TypeUsage. Каждый раз нужно явно прописывать к каким классам относится эта связь, а к каким не относится. Данный вариант особенно усложняется, если добавляется external-класс из соседнего проекта.
• Наследование не позволяет переопределить мастера или детейл.

Предложение

Для преодоления проблем с наследованием, нам нужен новый тип связи в UML-редакторе: Реализация. Данный тип связи должен работать следующим образом: в реализующий класс явно переносятся все атрибуты, мастера, детейлы и представления базового класса.
Для ассоциаций надо «разрубить» концепцию TypeUsage для классов со связями Реализация. Не должно генерироваться несколько ссылок на таблицы вида _m0, _m1 и т.д.. Связь должна быть в одном экземпляре.
Предлагается использовать отдельные NuGet-пакеты для сохранения UML-метаданных проекта и публикации их в NuGet-галерею с понятной моделью версионирования. На диаграмме добавить класс со стереотипом NuGet, который будет принимать имя и версию вида «[email protected]». Все метаданные данного пакета должны стать доступны для проектирования. При переустановке версии – должны удалиться прежние метаданные и добавиться новые. Надо подумать как бороться с пересечением имён. Проверять валидность моделей при переустановке пакетов.
Может быть, имеет смысл добавить отдельный стереотип для классов из пакета или даже добавить диаграммы из пакета, пометив их каким-то образом.
При упаковке модели в пакет нужно генерировать полное описание (брать из метаданных класса, описывающего этот пакет).
Подумать над вариантом, когда из одной стадии мы можем получить несколько NuGet-пакетов с метаданными. Таким образом надо размечать какие метаданные к какому пакету относятся (свойство Packet). Пакеты могут быть зависимыми друг от друга.
При добавлении на диаграмму ссылки на NuGet-пакет с моделью надо предоставить возможность быстрого добавления на диаграмму классов из этого пакета. При добавлении класса из пакета автоматически добавлять его атрибуты, мастера, детейлы и наследование от интерфейсов (интерфейсы помечаем как externalintarface, к ним должны быть привязаны бизнес-сервера).

Новые стереотипы:

• «nugetreference» - ссылка на NuGet-пакет с метаданными.
• «nugetpackage» - указание на то, что эта стадия упаковывается в NuGet-пакет. Описание пакета берётся из этого пакета. Ссылки на другие пакеты вычисляются автоматически через связи классов из этого пакета.
• «nugetimplementation» - класс из NuGet-пакета. При создании связи Реализация копируются атрибуты, методы, Storage, связи (надо продумать в какой момент, возможно, при сохранении диаграммы; что делать при переустановке пакета).
• «nugetenumeration» - перечисление из NuGet-пакета. Реализация может полностью изменять состав атрибутов.
• «nugetinterface» - интерфейс из NuGet-пакета
• «nugeteditform» - форма редактирования из NuGet-пакета (можно переопределить представление, которое ей используется).
• «nugetlistform» - форма списковая из NuGet-пакета (можно переопределить представление, которое ей используется).

Новые связи:

• Realization – аналогична наследованию, но без реального наследования просто копируется атрибутивный состав и методы класса. Ближе всего это похоже на прототипное наследование.

Пример модели с модульностью

Call to action

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

[vborovin]

Несколько вопросов:

1. При использовании Realization атрибутный состав, методы и тд будут дублироваться и в коде, или только в диаграммах? Если и в коде, то класс не будет фактически наследоваться от указанного прототипа? Как быть с дублированием кода?
2. Т.е. каждый пакет создает отдельные, ненаследуемые интерфейсы?
3. Как в таком сетапе правильно спроектировать иерархию модулей/пакетов/аддонов? Например, если в проекте есть большое количество различных сущностей, которые хотелось бы разделить на полностью независимые блоки, при этом иметь гибкую возможность соединять их между собой (с возможностью наследования и переопределения этих соединений).
   
4. Как можно правильно организовать подобную ситуацию? Например, в Ember можно было бы воспользоваться миксинами, но не в C#. Идея с Realization могла бы помочь, путем наличия нескольких независимых классов с полным атрибутным составом, но как быть в случае, если в приложении нужно сослаться одновременно на поля из двух реализаций? Кастовать не получится, придется несколько раз догружать один и тот же объект? Или завести еще одну реализацию в диаграмме приложения, которая будет ссылаться двумя Realization ссылками на нужные классы? Или же вообще лучше избегать таких ситуаций?
   

[bratchikov]

1. Класс будет дублироваться в коде. Это не так страшно, поскольку всегда генерируется с модели и подход Model-First позволяет гарантировать согласованность дублированного кода. При перегенерации код будет согласованным и не будет истории с расхождениями. Опять же версионирование NuGet-пакетов с базовыми модулями позволяет управлять процессом обновления.
2. Ограничений на наследование интерфейсов точно нет. Именно интерфейсы легко можно наследовать, там и множественное наследование есть - всё очень логично для модулей.
3. Надо попробовать нарисовать эту конкретную историю. Задача переопределения как раз и решается данным подходом. Другое дело, что удалять при переопределении всё ещё нельзя. Это, наверное, можно положить в основу идеи перепроектирования: стараться уложить модули таким образом, чтобы они расширялись вверху вниз, не допуская крупные лишние куски. Второй момент: соединения будут между конкретными классами, а не модулями в целом, надо помнить про это.
4. Реализация прекрасно поддерживает множественное наследование (складываем всё в одну кучу). Усложнение модели тут происходит в двух аспектах: надо все BS-ы перевести на интерфейсы, чтобы они срабатывали в т.ч. у конечных реализаций (явно добавляем наследование от интерфейса с BS). Второй момент - так как код не копируется, а генерируется каждый раз, то любая кастомная логика должна быть вынесена в отдельные библиотеки (надо продумать как правильно работать с вычислимыми полями).

[vborovin]

2. В примере в посте интерфейс IUserAccountAgent не наследуется от IAgent. Вопрос скорее с точки зрения проектирования, нужно ли параллельно иерархии реализации выстраивать иерархию наследования интерфейсов? Или они должны быть независимыми, как в примере? Какой вариант является более правильным?

[vborovin]

Также возникла пара вопросов:

1. Интерфейсы в данном случае используются только для сохранения иерархии вызова БСов в переопределенных модулях? Во всех остальных случаях (особенно связях между классами) всегда используются сами классы?
2. Нужно ли переносить весь атрибутный состав класса в интерфейс? Или какую его часть?
3. Если я правильно понял, будут дублироваться только переопределенные классы? В таком случае, как будут разрешаться ссылки между классами, если целевой класс переопределен? На примере из поста это ApplicationUser. Особенно если класс Agent не будет переопределен, только ApplicationUser. Реализация ведь не наследует явно переопределяемый класс, а дублирует его?
4. Как будут определяться неймспейсы переопределенных классов?

[s-andrey]

от классов с какими стереотипами можно делать реализацию? (сейчас только от implementation и Interface)

[vborovin]

Оставшийся фидбэк:

• Неудобно в каждой стадии повторно заводить все typedef в карте типов БД и C#, в том числе и пришедшие от nuget типов. Возможность автоматически заполнять typedef из nuget стадии была бы отличной
• Ember и SQL генерируют все nuget... классы из подключенных nugetreference'ов
• При выборе стадии на генерацию показываются также все пришедшие из nuget стадии
• При использовании ассоциации на nugetimplementation генерируется неправильный неймспейс
• Хотелось бы автоматическую публикацию стадий в NuGet
• Дизайнер не поддерживает GitLab NuGet
• Хотелось бы иметь возможность отключать генерацию с префиксами неймспейса для фронта, т.к. в модульной схеме они практически никогда не пересекаются с бэкендом (они должны быть одинаковыми на фронте для переопределения моделей и тп, но разными на бэкенде для непересечения и сосуществования в OData)