OpenSpace 2010 - MEF

OpenSpace 2010 var en riktig höjdare! Många intressanta diskussioner hölls, bla. "Molnet eller dimman" (Azure), "Default Architecture" (saker man bara tar för givet utan att ifrågasätta, INNAN man sätter sin arkitektur), "Visual Studio 2010 & .NET Framework 4.0 - Hot or Not?" (ganska självförklarande) ...

Själv ledde jag en diskussion om MEF (se mitt tidigare inlägg här). Diskussionen handlade om vad MEF kan användas till, vilka direkta svagheter vi ser och vad som måste finnas på plats innan vi kan använda oss av tekniken. Inledningsvis lyfte jag fram tankar och idéer som att MEF, genom sitt tydliga upplägg, gör det lättare för oss att komponentifiera vår applikationsfunktionalitet (någonting vi alltid har strävat efter), testa dessa komponenter isolerat och sedan ladda in dessa komponenter vid behov i vår applikation.

Under diskussionen, kom vi fram till att klassiska provider models (exempelvis ASP.NETs) känns naturliga att MEFifiera. Istället för att tydligt deklarera providerspecifika inställningar OCH referera till den implementerande DLL:en, resonerade vi att man, med hjälp av MEF, kan importera sina providers från sin bin-katalog.

Vi talade även om hur line-of-business-applikationer kan dra nytta av MEF. Genom att, exempelvis, dela upp vyerna (tabbarna?) i ett klassiskt orderhanteringssystem i separata komponenter som importeras i runtime av MEF, kan man partiellt uppdatera sin applikation med mindre impact än att släppa ett fullständigt paket. Vi resonerade kring hur detta möjliggör mindre, och tätare uppdateringar av applikationen, då man inte behöver vänta in nästa stora release för att uppdatera "den där hemska textboxen på den där tabben". I ett intranätscenario, kan man släppa en väldigt tunn bootstrapperapplikation (som ex. sköter autentiseringen), vilken sedan ansvarar för att läsa in hela sin applikationslogik och användargränssnitt från en nätverksenhet. På så sätt får man fördelen att köra lokalt (Code Access Security), samtidigt som man får en ökad möjlighet att uppdatera delar av applikationen utan att behöva distribuera ut den till samtliga klienter.

Allt är dock inte frid och fröjd. Den uppenbara faran vi tyckte oss se med MEF, var att all lättillgänglig komponentifiering skulle inbjuda till skapande av "onda" plugins, ex. en plugin för e-postskickning som också loggar all känslig e-post någonstans för senare missbruk.

Men å andra sidan, nämn en "bra" teknologi som inte kan missbrukas i händerna på "fel" personer :)