Как да избегнете свързването при използване на региони в 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 като общи библиотеки и имам няколко приложения, които ги използват. Инфраструктурният проект предоставя рамков код и ресурси (като MVVM неща, отражение, икони), а моята Shell е общ прозорец на хост с основното оформление на прозореца (менюта, ленти с инструменти, лента на състоянието, област с основно съдържание). Всички приложения споделят общ външен вид и се държат по подобен начин, защото споделят обвивката.

Моите приложения получават индивидуалната си функционалност от модулите, които се зареждат, така че имам проект за стартиране на приложение, който събира всичко заедно (infra, shell, модули).

Предполагам, че ако някога трябва да разработя чисто ново приложение, което е много различно от настоящите, ще мога да използвам повторно инфраструктурния проект, но не и обвивката. Ето защо съм любопитен относно отделянето на инфраструктурния проект от корпуса.


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