Wybór pomiędzy MEF i MAF (System.AddIn)

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

Jeśli oglądasz filmy o systemie.Addins, wyraźnie mówią o bardzo dużych projektach. Mówi o jednym zespole zarządzającym aplikacją hosta, innymzespole zarządzającym każdym dodatkiem, a trzecimzespole zarządzającym kontraktem i rurociągiem. Bazując na tym, myślę, że System.Addins jest wyraźnie dla większych zastosowań. Myślę o takich aplikacjach jak systemy ERP jak SAP (może nie aż tak duże, ale dostajesz pomysł). Jeśli oglądałeś te filmy, możesz powiedzieć, że ilość pracy w systemie.Addins jest bardzo duży. Byłoby dobrze, gdybyś miał wiele firm programujących dodatki innych firm dla swojego systemu i nie możesz złamać żadnej z tych umów dodatków pod karą śmierci.

Z drugiej strony, MEF wydaje się mieć więcej podobieństw do schematu dodatków SharpDevelop, architektury wtyczek Eclipse lub Mono.Addins. Jest to o wiele łatwiejsze do zrozumienia niż System.Addins and I believe it być bardziej elastycznym. Rzeczy, które tracisz, to to, że nie dostajesz izolacji AppDomain lub silnych kontraktów wersjonowania po wyjęciu z pudełka z MEF. Mocną stroną MEF jest to, że możesz uporządkować całą aplikację jako kompozycję części, dzięki czemu możesz wysył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 zobaczy ją i uruchomi. Ułatwia również testuję. Możesz utworzyć instancję obiektu, który chcesz przetestować, i podawać mu wzorce obiektów dla wszystkich jego zależności, ale gdy działa jako aplikacja złożona, proces kompozycji automatycznie łączy wszystkie rzeczywiste obiekty razem.

Najważniejszą kwestią, o której chciałbym wspomnieć, jest to, że mimo iż SystemAddins jest już w frameworku, nie widzę zbyt wielu dowodów na to, że ludzie go używają, ale MEF siedzi tylko na Codeplexie podobno ma być włączony do. Net 4, a ludzie już zaczynam budować z nim 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 MAF są nieco znużone.

MAF jest układem "sprzężonym" lub w najgorszym przypadku "luźno sprzężonym". MEF jest systemem "sprzężonym" lub co najwyżej "luźno-parowym".

Korzyści MAF, które zrealizowaliśmy używając MAF to:

1. Instalowanie nowych lub aktualizowanie istniejących komponentów podczas działania aplikacji. Dodatek może być aktualizowany, gdy aplikacja była uruchomiona, a aktualizacje pojawiają się dla użytkownika bezproblemowo. Musisz mieć do tego AppDomains.

2. Licencjonowanie na podstawie zakupionych komponentów. Możemy kontrolować, które Dodatki zostały załadowane przez rolę i uprawnienia użytkownika oraz czy dodatek został licencjonowany do użytku.

3. Szybki rozwój (szybszy czas wprowadzenia na rynek). Rozwój AddIn doskonale pasuje do zwinnej metody, zespół programistów opracowywał jeden AddIn na raz, bez konieczności również rozwijania elementu integracji z resztą podanie.

4. Poprawiono QA (tylko QA jeden komponent na raz). QA może następnie testować i wystawiać usterki dla pojedynczego bitu funkcjonalności. Przypadki testowe były łatwiejsze do opracowania i wdrożenia.

5. Wdrożenie (dodawanie komponentów w miarę ich opracowywania i wydawania i "po prostu działają"). Wdrożenie to tylko kwestia dodania i zainstalowania pliku. Żadne inne rozważania nie były konieczne!

6. Nowe komponenty pracowały ze starymi komponentami. AddIn które zostały opracowane na wczesnym etapie pracy. Nowe dodatki bezproblemowo dopasowują się do aplikacji

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

MEF jest zazwyczaj najlepszy w scenariuszu czystego wtrysku zależności, gdzie osoba lub grupa dostarczająca ostateczne zintegrowane rozwiązanie składa wszystko i ręczy za ogólną integralność, ale ma potrzebę różnych implementacji kluczowych możliwości.

MAF jest dla scenariusza, w którym ktoś / Grupa rozwija platformę lub hosta, a inne grupy dodadzą możliwości po fakcie i w sposób nie podlegający kontroli grupy gospodarzy. W tym scenariuszu potrzeba bardziej rozbudowanych mechanizmów, aby "chronić" hosta przed nieuczciwymi dodatkami(lub chronić dodatki przed sobą).

Trzecią podobną technologią jest cały schemat ProviderBase. Umożliwia to również zastąpienie funkcji, ale jej celem jest naprawdę scenariusz, w którym host / aplikacja absolutnie potrzebuje możliwości i naprawdę trzeba określić różne implementacje 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 przez inne odpowiedzi, wydaje się, że jedną z kluczowych różnic między MEF i MAF jest to, że zarządzane ramy rozszerzalności pozwoliłyby jednej składającej się części zależeć od drugiej. Pozwala to na to, aby wtyczka zależała na przykład od innej wtyczki.

Zarządzana Rozszerzalność Framework również tak naprawdę nie rozróżnia między hostem a dodatkiem, jako systemem.AddIn ma. Jeśli chodzi o MEF, wszystkie są tylko komponowalnymi częściami.

Moim zdaniem najlepszym sposobem na odkrycie różnic jest praktyczny kod. Znalazłem dwa solucje MSDN, oba z przykładowym kalkulatorem, dzięki czemu można łatwo porównać ich implementacje:

MEF: prosty przykład kalkulatora z wykorzystaniem części MEF
(M anaged E xtensibility F ramework)

• pokazuje jak zbudować prosty kalkulator przy użyciu technologii MEF. Nie pokazuje, jak ładować zewnętrzne biblioteki DLL. (Ale można wystarczy zmodyfikować przykład używając catalog.Catalogs.Add(new DirectoryCatalog("Plugins", "*.dll")); zamiast używać catalog.Catalogs.Add(new AssemblyCatalog(typeof(Program).Assembly)); i wyodrębnić kod kalkulatora i umowa do oddzielenia projektów DLL.)

• MEF nie musi mieć określonej struktury katalogów, jest prosty i prosty w użyciu, nawet dla małych projektów. To działa z atrybutami, aby zadeklarować to, co jest eksportowane, co jest łatwe 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 zajmuje się automatycznie wersjonowanie

MAF: Simple calculator with v1 and v2 version MAF plugins
(M anaged A ddin F ramework)

• pokazuje, jak zbudować kalkulator za pomocą wtyczki V1, a następnie jak przejść do wtyczki V2 przy zachowaniu kompatybilności wstecznej (Uwaga: Możesz znaleźć wersję V2 wtyczki tutaj, link w oryginalnym artykule jest uszkodzony)
• MAF wymusza specyficzną strukturę katalogów , i potrzebuje dużo kodu boilerplate, aby to działało, dlatego nie polecam go dla małych projektów. przykład:

  Pipeline
    AddIns
      CalcV1
      CalcV2
    AddInSideAdapters
    AddInViews
    Contracts
    HostSideAdapters
  

MAF i MEF mogą używać AppDomains i oba mogą ładować/rozładowywać dll w trybie runtime. Jednak różnice, które znalazłem to: Dodatki MAF są odsprzęgane, komponenty MEF są luźno sprzężone; MAF "aktywuje" (nowa instancja), podczas gdy MEF domyślnie tworzy instancje.

Z MEF można użyć Generics zrobić GenericHost dla każdego kontraktu. Oznacza to, że MEF load / unload i zarządzanie komponentami mogą być we wspólnej bibliotece i używane ogólnie.