Wyobraźmy sobie, że budowanie aplikacji tak proste, jak budowanie domku z klocków, gdzie poszczególne elementy (klocki) są połączone w całość (domek) podczas zabawy (życia domku). Przecież coraz częściej zachodzi potrzeba budowy aplikacji tak, aby składała się ona z luźno związanych komponentów, które ulegają kompozycji dopiero podczas działania aplikacji. Właśnie na takie podejście pozwala MEF, czyli „Managed Extensibility Framework", nowa biblioteka wchodząca w skład .NET Framework 4.0. Chciałbym wszystkich zainteresowanych zaprosić na moją prezentację "Wprowadzenie do Managed Extensibility Framework w .NET 4.0", którą pokażę na najbliższym spotkaniu Łódzkiej Grupy Profesjonalistów IT & .NET. Niniejsza sesja ma za zadanie wprowadzić słuchacza w zagadnienia związane z „Managed Extensibility Framework", wskazać potencjalne zastosowania oraz pokazać przykładową aplikację.

1. Wprowadzenie do MEF w .NET 4.0 Autor: Maciej Zbrzezny Łódzka Grupa Profesjonalistów IT & .NET

2. O mnie Nazywam się Maciej Zbrzezny Pracuje w firmie CAS, w której jest architektem oprogramowania i programistą, współtworzę tam oprogramowanie do komunikacji w rozproszonych systemach automatyki przemysłowej i integracji z systemami biznesowymi (rodzina oprogramowania: CommServer). Tworzę oprogramowanie wykorzystujące platformę .NET(głównie C#) i standard OPC. Autor bloga „Programowanie i Technologie” (http://maciej-progtech.blogspot.com/). Posiadam certyfikaty MCTS z obszaru ASP.NET i Windows Forms Applications. maciejzbrzezny@gmail.com

3. MEF Managed Extensibility Framework Makes Extensibility Fun

4. Rozszerzalność Przede wszystkim! Po co to wszystko?

5. Rozszerzalność – pożądana Deweloperzy, architekci oprogramowania od zawsze myślą o tym: By ich aplikacje były rozszerzalne By można było dodawać nowe elementy bez potrzeby ich ponownej rekompilacji By aplikację można było rozszerzać łatwo i bez dużego nakładu pracy

6. Brak standardu Firefox (dlaczego stał się taki popularny? Dlaczego Opera traciła?) Office ma swój model – ale tylko dla Office’a ASP.NET ma swój dzięki provider’om SharpDevelop - SODA …

7. Rozszerzalność może być pułapką Trudno osiągnąć, a często jeszcze trudniej używać

8. Rozszerzalność powinna być prosta

9. IoC / DI Na co jeszcze pozwala MEF?

10. IoC / DI – o co chodzi? Masz problem – odwróć zależności. Coraz popularniejsze staje się wykorzystanie wzorców bazujących na DependencyInjection (DI) i Inversion Of Control (IoC) Zasada odwracania zależności: Moduły wysokopoziomowe nie powinny zależeć od niskopoziomowych (obie grupy niech zależą od abstrakcji) Abstrakcje nie powinny zależeć od szczegółowych rozwiązań (a na odwrót)

11. IoC/ DI MEF skupia się na rozszerzalności aplikacji ale może być też wykorzystany do czegoś innego. MEF używa DI/IoCjako strategii pozwalającej na komponowanie różnych rozszerzeń, ale nie jest typowym generycznym kontenerem DI /IoC.

12. Przykład MEF dla DI/IOC Zdekomponowana aplikacja MEF DI/IOC MEF DI/IOC Warstwa Dostępu do Danych Obiekty Biznesowe Interfejs użytkownika MEF Import Wnętrze aplikacji (wszystkie komponenty znane) Dostawca danych z SQL Server Dostawca danych z Oracle Server Na zewnątrz aplikacji (komponenty nie znane)

13. MEF a kontener IoC - różnice MEF Odkrywanie (Discovery) Otwarte zestawy Wiązania części z zestawu Brak zewnętrznej konfiguracji Kontener IoC Rejestracja Zamknięte zestawy Wiązania ścisłe Zwykle zewnętrzna konfiguracja

14. Wprowadzenie MEF

15. Dlaczego i jak powstał? Microsoft o dawna myślał: „Jak tworzyć aplikacje z wielo-używalnych (resuable) komponentów, które mogą być odkrywane, używane i składane dynamicznie”?: Visual Studio 2010 i nowy rozszerzalny edytor dla programisty. „Oslo” i edytor „Intellipad”, który korzysta z MEF, by zapewnić rozszerzalność w oparciu o skrypty (pluginy) napisane w IreonPython’nie „Acropolis” i framework wspierający budowanie aplikacji kompozytowych, podczas działania odkrywane były komponenty aplikacji i związane z nimi serwisy, a do konfiguracji wykorzystywany XAML. Problem rozszerzalności nie dotyczył tylko Microsoftu. Konsumenci-programiści od lat sami implementowali własne mechanizmy rozszerzeń. Microsoft postanowił jednak zrobić krok i wyjść naprzód swoim i innych potrzebom.

16. Dlaczego potrzebujemy czegoś nowego? MEF nie jest pierwszym rozwiązaniem, który wspiera wspomniane wcześniej funkcjonalności. Było i jest wiele proponowanych rozwiązań: Java: EJB, CORBA, OSGIw Eclipse (czyli projekt Equinox), framework Spring. Microsoft: COM, System.Addinw .NET Framework open source: architektura SODA wSharpDevelopi kontenery IoCjak Castle Windsor, Structure Map czy Unity z Patterns& Practices. Żadne z powyższych nie jest idealne MEF jest wyciągnięciem wniosków z tych wszystkich.

17. MEF narodzenie Na CodePlexpowstaje projekt MEF (sierpień 2008): http://mef.codeplex.com/ MEF staje się częścią .NET 4.0, jako System.ComponentModel.Composition usingSystem.ComponentModel.Composition; usingSystem.ComponentModel.Composition.Hosting;

18. Typowy scenariusz Aplikacja Potrzebuję paska narzędziowego Potrzebuję Menu Ja mam paska narzędziowy Ja mam Menu Rozszerzenie B Rozszerzenie A

19. Interfejsy, czyli wstęp do plugin’ów Interfejs: Implementacja interfejsu (plugin): http://maciej-progtech.blogspot.com/2010/05/jak-zaimplementowac-mechanizm-wtyczek.html

20. Przed erą MEF … Gotowy program: http://maciej-progtech.blogspot.com/2010/05/jak-zaimplementowac-mechanizm-wtyczek.html

21. W erze MEF: Programowanie atrybutami (Attributed Programming Model)

22. DEMO MEF w praktyce …

23. 1, 2, 3, 4 … MEF start Podstawy, czyli

24. Po pierwsze: Część (Composable Part) Jest to podstawowy element (fragment, część) Jest to fragment aplikacji, która jest pewnego rodzaju układanką Podczas działania aplikacji wszystkie jej części są „komponowane” w całość Part

25. Po drugie: Kontrakt łączy części (1) Part B Part A Contract Poszczególne części nie zależą od siebie nawzajem, zależą natomiast od kontraktu Kontrakt (ang. Contract) to pewnego rodzaju pomost pomiędzy różnymi częściami To deklaracja, że pewne dwie części mogą ze sobą współpracować Każda część (Part) powinna zawierać przynajmniej jedno powiązanie z kontraktem

26. Part B Part A Po drugie: Kontrakt łączy części (1) Contract Kontrakt zwykle oznaczany strzałką

27. Po drugie: Kontrakt łączy części (2) Part A Part B Import Export Import jest kontraktem, który określa, że część go potrzebuje Export jest kontraktem, który określa, że część go oferuje Każdy Part powinien zawierać przynajmniej jeden import lub export

28. Po drugie: Kontrakt łączy części (2) Part A Part B Import Export Import jest kontraktem, który określa, że część go potrzebuje Export jest kontraktem, który określa, że część go oferuje Każdy Part powinien zawierać przynajmniej jeden import lub export

29. Po drugie: Kontrakt łączy części (3) Import Part Export Import Export Import

30. Po trzecie: Kontener (Container) (1) Container Dokonuje on kompozycji (wiąże / składa poszczególne części) Kontener wykorzystuje informacje o kontraktach by dokonać kompozycji Kompozycji dokonuje tak, jak to jest wymagane i możliwe Jeżeli czegoś brakuje, to przyjmuje, że nie jest potrzebne i pomija (chyba że oznaczymy, że to jest wymagane i wtedy otrzymamy wyjątek) Composition Import Export Part Import Export Import

31. Po trzecie: Kontener (Container) (2) Container

32. Po czwarte: Katalog Katalog jest miejscem skąd pobierane są części do kontenera Dostępne katalogi: AssemblyCatalog DirectoryCatalog AgragateCatalog TypeCatalog DeploymentCatalog (Silverlightonly) FilteringCatalog

33. Opóźniona inicjalizacja (Lazyloading?) Part B Part <A> Wczytywanie wszystkiego na raz może być czasochłonne i zasobochłonne –przykład menu z wielu assembly MEF oferuje opóźnioną inicjalizację Zamiast konkretnego importu oferuje pewien wrapper (wrapper of the contract) który go opakowuje. Part B Part <A> Part A Lazy<T, TMetadata>

34. Metadane Element związany z lazyloading Umożliwia dodawanie do części pewnych znaczników, czy atrybutów Wartości Metadanych pojawiają się wcześniej (zanim wczytane będą prawdziwe party Metadane mogą być słabo i silnie typowane

35. Czas życia części Singleton Factory Container Container Part A Part A Part A Part A [PartCreationPolicy( CeationPolicy.NonShared)] [PartCreationPolicy( CeationPolicy.Shared)]

36. DEMO MEF w praktyce …

37. MEF podsumowanie (1) MEF jest rozwiązaniem dla problemu rozszerzania: Nie trzeba tworzyć własnej infrastruktury. Plugin’y mogą być wielo-używalne. MEF dostarcza mechanizmy wspomagające IoC/DI – ale nie jest generycznym kontenerem IoC Assembly aplikacji głównej Assembly opisu kontraktów Assembly plugin’ów Part 1 Part 3 Part 2 [Import] [Export]

38. MEF podsumowanie (2) MEF zapewnia standardową rozszerzalność MEF oferuje mechanizmy odkrywania i lokalizowania elementów oraz ładowania rozszerzeń. MEF pozwala na oznaczanie rozszerzeń pewnymi metadanymi, które później można odczytywać, odpytywać, czy filtrować.

39. MEF podsumowanie (3) Zaleta poza-funkcjonalna: MEF jest częścią .NET 4.0 !!!

40. Gdzie szukać informacji MEF na Codeplex (dokumentacja, przykłady, kod źródłowy, linki do blogów twórców): http://mef.codeplex.com MSDN: Wprowadzenie do Mef: http://msdn.microsoft.com/en-us/library/dd460648.aspx MSDN, namespaceSystem.ComponentModel.Composition: http://msdn.microsoft.com/en-us/library/system.componentmodel.composition.aspx MSDN Magazine: http://msdn.microsoft.com/en-us/magazine/ee291628.aspx http://msdn.microsoft.com/en-us/magazine/gg650670.aspx Kontakt do mnie: maciejzbrzezny@gmail.com, http://maciej-progtech.blogspot.com

41. Dziękuję za uwagę