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

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

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

<ItemsControl cal:RegionManager.RegionName="{x:Static inf:RegionNames.TabRegion}">
public static class RegionNames
{
    public const string TabRegion = "TabRegion";
}

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

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

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


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

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

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

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

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


person M. Dudley    schedule 29.04.2010    source источник
comment
Я думаю, что моя посылка все еще в силе. Оболочка - это просто чистый холст. Фактическая функциональность обеспечивается модулями и инфраструктурным проектом. Вы говорите, что у вас есть несколько приложений, использующих одну и ту же оболочку и инфраструктурное приложение? Почему они не просто модули в вашей оболочке? Я пишу такое же сложное приложение, каждое приложение - это отдельный модуль с подобластями и т. Д. Для представлений этих модулей. Это может быть довольно сложно, но, на мой взгляд, вы усложняете вещи на более высоком уровне, чем вам нужно.   -  person ecathell    schedule 30.04.2010
comment
если вас беспокоят проблемы безопасности или варианты использования, вы всегда можете загрузить свои модули на основе ролей безопасности. Я определенно сказал бы начать как можно проще, потому что вы можете быстро погрузиться в детали PRISM. Я знаю, что у меня есть, мне приходилось возвращаться и реорганизовывать несколько раз из-за непонимания с моей стороны. И я все еще недоволен, но сроки приближаются, и мне нужно хотя бы заставить его работать.   -  person ecathell    schedule 30.04.2010
comment
Я не уверен, понял ли я ваш первый комментарий, но у каждого приложения есть свои собственные модули, которые размещены в оболочке. С точки зрения пользователя это отдельные приложения, но в исходном коде все они разделяют оболочку. Я разделяю код оболочки и код приложения.   -  person M. Dudley    schedule 30.04.2010


Ответы (1)


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

person ecathell    schedule 29.04.2010
comment
У вас другое представление о том, как компоненты работают вместе, чем у меня, и я вижу достоинства вашей архитектуры. Я обновил свой вопрос, добавив более подробную информацию о том, как я вижу систему, просто для обсуждения. - person M. Dudley; 29.04.2010
comment
Я думаю, что @ecathell верен, и все составные приложения, в которых я участвовал, были разработаны так, чтобы модули могли изменяться независимо (насколько это возможно) от сборок оболочки и инфраструктуры / ядра. - person nrjohnstone; 27.02.2014