Как избежать связывания при использовании регионов в Composite WPF

Question

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

Во всех примерах, которые я видел, регионы определяются и доступны с помощью строки в статическом классе в проекте инфраструктуры.

<ItemsControl cal:RegionManager.RegionName="{x:Static inf:RegionNames.TabRegion}">

public static class RegionNames
{
    public const string TabRegion = "TabRegion";
}

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

Есть ли способ изолировать регионы оболочки, чтобы они определялись только внутри оболочки (без имен регионов в инфраструктурном проекте)?

Есть ли способ сделать регионы необязательными, чтобы оболочки могли быть заменены, даже если они не имеют одинаковые регионы? (Пример: одна оболочка имеет области меню и панели инструментов, другая имеет только меню... модули должны иметь возможность вставлять в панель инструментов, если она доступна, без сбоев, когда она отсутствует)

---

Обновление - Подробнее о моей архитектуре

В ответ на ответ depictureboy ниже, я хотел описать, как настроена моя система... возможно, будет больше хороших отзывов об этом.

Я рассматриваю проекты инфраструктуры и оболочки как общие библиотеки, и у меня есть несколько приложений, которые их используют. Проект "Инфраструктура" предоставляет "каркасный" код и ресурсы (например, материалы MVVM, отражения, значки), а моя оболочка представляет собой универсальное окно хоста с базовой компоновкой окон (меню, панели инструментов, строка состояния, область основного содержимого). Все приложения имеют общий вид и ведут себя одинаково, потому что они используют оболочку.

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

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

Answer 1

Я думаю, что у вас есть логика в обратном направлении. Ваша оболочка - это клей, который связывает все вместе. На мой взгляд, вы хотите, чтобы инфраструктура и оболочка были тесно связаны, потому что они являются приложением. Ваши модули - это части приложения, которые будут динамически изменяться и переключаться. Вы хотите, чтобы области вашей оболочки были статичными, чтобы, например, другой разработчик мог написать модуль для вашего приложения, зная, где будут размещаться его различные представления и как приложение должно вести себя с подключенным модулем. Проект "Инфраструктура" - это нечто среднее между вашей оболочкой и ее модулями... это просто факт жизни, по крайней мере, в моей книге. Один из гуру WPF может придумать что-то такое, что завтра вылетит из воды...