Wybieranie między MEF i MAF (System.AddIn)

Managed Extensibility Framework (MEF) i Managed AddIn Framework (MAF, inaczej System.AddIn) wydają się wykonywać bardzo podobne zadania. Zgodnie z tym pytaniem dotyczącym przepełnienia stosu, czy MEF jest zamiennikiem dla System.Addin? , możesz nawet używać obu jednocześnie.

Kiedy zdecydowałbyś się użyć jednego kontra drugiego? W jakich okolicznościach zdecydowałbyś się używać obu razem?

Oceniłem te opcje i oto wniosek, do którego doszedłem.

MAF to prawdziwa struktura dodatków. Możesz całkowicie oddzielić dodatki, nawet uruchamiając je w oddzielnej domenie aplikacji, aby w przypadku awarii dodatku nie spowodował wyłączenia aplikacji. Zapewnia również bardzo kompletny sposób oddzielenia dodatków od zależnych od czegokolwiek poza umową, którą im dajesz. W rzeczywistości można wersjonować adaptery umowy, aby zapewnić wsteczną kompatybilność ze starymi dodatkami podczas uaktualniania głównej aplikacji. Brzmi to świetnie, ale wiąże się to z wysoką ceną, którą musisz zapłacić, aby przejść przez domeny. Płacisz tę cenę w szybkości, a także za elastyczność typów, które możesz przesyłać tam iz powrotem.

MEF jest bardziej podobny do iniekcji zależności z pewnymi dodatkowymi korzyściami, takimi jak wykrywalność i ... (rysowanie pustego miejsca na tym). Stopień izolacji, który ma MAF, nie jest obecny w MEF. Są to dwie różne ramy dla dwóch różnych rzeczy.

To, co powiedział Danielg, jest dobre. Dodałbym:

Jeśli oglądasz filmy o System.Addins, wyraźnie mówią o bardzo dużych projektach. Opowiada o jednym zespole zarządzającym aplikacją hosta, innym zespole zarządzającym każdym dodatkiem, a trzecim zespole zarządzającym umową i potokiem . Na tej podstawie uważam, że System.Addins jest wyraźnie przeznaczony dla większych aplikacji. Myślę o aplikacjach, takich jak systemy ERP, takie jak SAP (może nie tak duże, ale masz pomysł). Jeśli obejrzałeś te filmy, możesz stwierdzić, że nakład pracy potrzebny do użycia System.Addins jest bardzo duży. Byłoby dobrze, gdybyś miał wiele firm programujących dodatki innych firm dla twojego systemu i nie możesz złamać żadnej z tych umów na dodatki pod groźbą kary śmierci.

Z drugiej strony, MEF wydaje się mieć więcej podobieństw do schematu dodatków SharpDevelop, architektury wtyczki Eclipse lub Mono.Addins. Jest dużo łatwiejszy do zrozumienia niż System.Addins i uważam, że jest dużo bardziej elastyczny. Przyczyną utraty jest to, że nie uzyskujesz izolacji AppDomain lub silnych kontraktów wersjonowania zaraz po wyjęciu z pudełka z MEF. Mocne strony MEF polegają na tym, że możesz uporządkować całą aplikację jako kompozycję części, dzięki czemu możesz wysłać produkt w różnych konfiguracjach dla różnych klientów, a jeśli klient kupi nową funkcję, po prostu upuść część dla tej funkcji do katalogu instalacyjnego a aplikacja widzi go i uruchamia. Ułatwia również testowanie. Możesz utworzyć instancję obiektu, który chcesz przetestować i podawać mu makiety obiektów dla wszystkich jego zależności,

Najważniejszą kwestią, o której chciałbym wspomnieć, jest to, że chociaż System.Addins jest już w frameworku, nie widzę zbyt wielu dowodów na to, że ludzie go używają, ale MEF siedzi tam na CodePlex, który podobno ma być włączony NET 4, a ludzie już zaczynają tworzyć za jego pomocą wiele aplikacji (w tym ja). Myślę, że to mówi coś o tych dwóch frameworkach.

Po opracowaniu i wysłaniu aplikacji MAF. Moje poglądy na temat MAF są nieco zblazowane.

MAF jest systemem „rozłączonym” lub w najgorszym przypadku systemem „luźnym”. MEF jest systemem „sprzężonym” lub w najlepszym przypadku systemem „luźno parowanym”.

Korzyści MAF, które osiągnęliśmy dzięki zastosowaniu MAF to:

1. Instalowanie nowych lub aktualizowanie istniejących komponentów podczas działania aplikacji. Dodatek można zaktualizować, gdy aplikacja była uruchomiona, a aktualizacje są wyświetlane użytkownikowi bezproblemowo. Musisz mieć do tego AppDomains.

2. Licencjonowanie na podstawie zakupionych komponentów. Mogliśmy kontrolować, które dodatki są ładowane przez rolę i uprawnienia użytkownika oraz czy dodatek jest licencjonowany do użytku.

3. Szybki rozwój (szybsze wprowadzenie produktu na rynek). Rozwój AddIn doskonale pasuje do metodologii Agile, zespół programistów opracował jeden dodatek na raz, bez konieczności opracowywania elementu integracji z resztą aplikacji.

4. Ulepszona kontrola jakości (kontrola jakości tylko jednego składnika na raz). Kontrola jakości może następnie przetestować i wydać usterki dla pojedynczego fragmentu funkcjonalności. Przypadki testowe były łatwiejsze do opracowania i wdrożenia.

5. Wdrażanie (dodawanie komponentów w miarę ich opracowywania i wydawania, a one „po prostu działają”). Wdrożenie to tylko kwestia utworzenia dodatku i zainstalowania pliku. Żadne inne względy nie były konieczne!

6. Nowe komponenty działały ze starymi komponentami. Dodatek, który został opracowany wcześnie, nadal działał. Nowe dodatki bezproblemowo dopasowują się do aplikacji

Moim zdaniem te dwie technologie są w rzeczywistości ukierunkowane na bardzo różne przypadki użycia.

MEF jest zwykle najlepszy w scenariuszu czystego wstrzykiwania zależności, w którym osoba lub grupa dostarczająca ostateczne zintegrowane rozwiązanie składa wszystko i ręczy za ogólną integralność, ale musi mieć różne implementacje kluczowych funkcji.

MAF dotyczy scenariusza, w którym ktoś / grupa opracowuje platformę lub hosta, a inne grupy dodadzą możliwości po fakcie iw sposób nie będący pod kontrolą grupy gospodarza. W tym scenariuszu potrzebne są bardziej wyszukane mechanizmy „ochrony” hosta przed nieuczciwymi dodatkami (lub wzajemna ochrona dodatków).

Trzecią technologią o podobnym wzorze jest cały schemat ProviderBase. Umożliwia to również zastąpienie możliwości, ale celem jest tak naprawdę scenariusz, w którym host / aplikacja absolutnie potrzebuje możliwości, a potrzeba naprawdę polega na określeniu różnych implementacji za pomocą konfiguracji.

Właśnie znalazłem ten długi artykuł omawiający zarówno MAF, jak i MEF. http://emcpadden.wordpress.com/2008/12/07/managed-extensibility-framework-and-others/

Oprócz punktów przedstawionych w innych odpowiedziach wydaje się, że jedną z kluczowych różnic między MEF i MAF jest to, że Managed Extensibility Framework pozwoliłby, aby jedna komponowalna część zależała od drugiej. Na przykład pozwoliłoby, aby wtyczka zależała od innej wtyczki.

Managed Extensibility Framework również tak naprawdę nie rozróżnia między hostem a dodatkiem, tak jak robi to System.AddIn. Jeśli chodzi o MEF, wszystkie są po prostu komponowalnymi częściami.

Moim zdaniem najlepszym sposobem na odkrycie różnic jest praktyczny kod. Znalazłem dwie instrukcje MSDN, obie z przykładem kalkulatora, dzięki czemu możesz łatwo porównać ich implementacje:

MEF: przykład prostego kalkulatora wykorzystującego części MEF
( M anaged E kstensibility F ramework )

• Pokazuje, jak zbudować prosty kalkulator przy użyciu technologii MEF. Nie pokazuje, jak załadować zewnętrzne biblioteki DLL. (Ale możesz po prostu zmodyfikować przykład, używając catalog.Catalogs.Add(new DirectoryCatalog("Plugins", "*.dll")); zamiast używania catalog.Catalogs.Add(new AssemblyCatalog(typeof(Program).Assembly));i wyodrębniania kodu kalkulatora i kontraktu do oddzielnych projektów DLL.)

• MEF nie musi mieć określonej struktury katalogów, jest prosty i łatwy w użyciu, nawet w przypadku małych projektów. To działa z atrybutami, aby zadeklarować, co jest eksportowane, który jest łatwy do odczytania i zrozumienia. Przykład: [Export(typeof(IOperation))] [ExportMetadata("Symbol", '+')] class Add: IOperation { public int Operate(int left, int right) { return left + right; } }

• MEF nie obsługuje automatycznie wersjonowania

MAF: Prosty kalkulator z wtyczkami MAF w wersji V1 i V2
( M anaged A ddin F ramework )

• Pokazuje jak zbudować kalkulator za pomocą wtyczki V1, a następnie, jak poruszać się do wtyczki V2 równocześnie zachowując wsteczną kompatybilność ( uwaga: można znaleźć wersję V2 wtyczki tutaj , link do oryginalnego artykułu jest uszkodzony)
• MAF wymusza określoną strukturę katalogów i potrzebuje dużo standardowego kodu, aby działał, dlatego nie polecam go dla małych projektów. Przykład:

  Pipeline
    AddIns
      CalcV1
      CalcV2
    AddInSideAdapters
    AddInViews
    Contracts
    HostSideAdapters

Zarówno MEF, jak i MAF są zawarte w .NET Framework 4.x. Jeśli porównasz te dwa przykłady, zauważysz, że wtyczki MAF mają dużo większą złożoność w porównaniu z frameworkiem MEF - musisz więc dokładnie przemyśleć, kiedy użyć którego z tych frameworków.

MAF i MEF mogą używać AppDomains i oba mogą ładować / zwalniać bibliotekę dll w czasie wykonywania. Jednak różnice, które znalazłem, są następujące: Dodatki MAF są oddzielone, komponenty MEF są luźno połączone; MAF „Aktywuje” (nowa instancja), podczas gdy MEF domyślnie tworzy instancje.

Za pomocą MEF można użyć Generics do tworzenia GenericHost dla dowolnego kontraktu. Oznacza to, że ładowanie / zwalnianie MEF i zarządzanie komponentami mogą znajdować się we wspólnej bibliotece i być używane ogólnie.