Как избежать связывания при использовании регионов в Composite WPF - PullRequest
0 голосов
/ 29 апреля 2010

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

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

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

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

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

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

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


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

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

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

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

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

1 Ответ

2 голосов
/ 29 апреля 2010

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

...