Resourcer i Prism
En af de ting, som vil blive en udfordring for os, når vi indfører Prism, er at eftersom alt er opbygget i moduler, bliver det noget sværere at dele ResourceDictionaries. Vores første forsøg med at lægge et dictionary i en assembly som alle moduler har kendskab til – og så inkludere filen i modulerne er slået fejl. Egentlig burde det virke, men Visual Studio har temmelig store problemer med det. Den nægter at finde resourcer, nægter at builde osv.
Det vi nok kommer til at gøre (og som i øvrigt er best practise) er at lægge alt i App.xaml. Problemet her, er at eftersom App.Xaml ligger i et helt tredje assembly, som modulerne ikke kan se, bliver vi nødt til at påkoble dem run-time. Det kan virke som en uoverstigelig hindring – men lige præcis i vores tilfælde er det ikke så slemt, fordi vi danner vores kontroller dynamisk i små hjælpeklasser. Vi er godt nok afhængige af at kunne stave ens… men med nogle gode tests, kan det også sagtens lade sig gøre.
Derudover kommer vi til at skulle lave vores ICommands og StyleSelectors og den slags i de assemblies, de hører hjemme – i øjeblikket ligger alt i en Presentation.dll – men det er kun et spørgsmål om fordeling – der skal som sådan ikke laves noget om rent funktionsmæssigt.
Det vi vinder ved alt dette bøvl, er at vores dictionaries bliver noget mere overskuelige – bare med den smule funktionalitet vi har på plads nu, er de efterhånden temmelig omfangsrige, selvom vi har fordelt alle resourcerne over flere dictionaries. I det hele taget bliver vi ‘tvunget’ til at overveje vores struktur noget mere nøje – hvilket ikke ubetinget er en dårlig ting… Det bliver nu rart at have koncentrerede moduler som kun indeholder funktionalitet til et specifikt afgrænset område. Enkapsulering bliver et af kodeordene.