Khung mở rộng được quản lý (MEF) và Khung AddIn được quản lý (MAF, còn gọi là System.AddIn) dường như hoàn thành các nhiệm vụ rất giống nhau. Theo câu hỏi Stack Overflow này, MEF có phải là sự thay thế cho System.Addin không? , bạn thậm chí có thể sử dụng cả hai cùng một lúc.
Khi nào bạn sẽ chọn sử dụng cái này so với cái kia? Trong hoàn cảnh nào bạn sẽ chọn sử dụng cả hai cùng nhau?
Câu trả lời:
Tôi đã đánh giá các tùy chọn này và đây là kết luận mà tôi đã đưa ra.
MAF là một khung addon thực sự. Bạn có thể tách hoàn toàn các addon của mình, thậm chí chạy chúng trong một miền ứng dụng riêng để nếu addon gặp sự cố, nó sẽ không gỡ ứng dụng của bạn xuống. Nó cũng cung cấp một cách rất đầy đủ để tách các addon khỏi tùy thuộc vào bất cứ điều gì ngoại trừ hợp đồng bạn đưa cho họ. Trên thực tế, bạn có thể phiên bản các bộ điều hợp hợp đồng của mình để cung cấp khả năng tương thích ngược với các addon cũ trong khi bạn đang nâng cấp Ứng dụng chính. Trong khi điều này nghe có vẻ tuyệt vời, nó đi kèm với một mức giá nặng mà bạn phải trả để vượt qua các tên miền appd. Bạn trả giá này theo tốc độ và cả tính linh hoạt của các loại mà bạn có thể gửi qua lại.
MEF giống như tiêm phụ thuộc hơn với một số lợi ích bổ sung như khả năng khám phá và ... (vẽ một khoảng trống trên cái này). Mức độ cô lập mà MAF có không có trong MEF. Chúng là hai khuôn khổ khác nhau cho hai thứ khác nhau.
Những gì Danielg nói là tốt. Tôi sẽ thêm:
Nếu bạn xem các video về System.Addins, họ rõ ràng đang nói về các dự án rất lớn. Anh ấy nói về một nhóm quản lý ứng dụng máy chủ, một nhóm khác quản lý mỗi AddIn và một nhóm thứ ba quản lý hợp đồng và đường ống dẫn. Dựa vào đó, tôi nghĩ System.Addins rõ ràng dành cho các ứng dụng lớn hơn. Tôi đang nghĩ các ứng dụng như hệ thống ERP như SAP (có thể không lớn lắm, nhưng bạn hiểu ý). Nếu bạn đã xem những video đó, bạn có thể nói rằng khối lượng công việc để sử dụng System.Addins là rất lớn. Nó sẽ hoạt động tốt nếu bạn có nhiều công ty lập trình bổ trợ bên thứ 3 cho hệ thống của bạn và bạn không thể phá vỡ bất kỳ hợp đồng bổ trợ nào dưới hình phạt tử hình.
Mặt khác, MEF dường như chia sẻ nhiều điểm tương đồng hơn với lược đồ bổ trợ của SharpDevelop, kiến trúc plugin Eclipse hoặc Mono.Addins. Nó dễ hiểu hơn nhiều so với System.Addins và tôi tin rằng nó linh hoạt hơn rất nhiều. Những điều bạn mất là bạn không bị cô lập AppDomain hoặc các hợp đồng phiên bản mạnh mẽ vượt trội với MEF. Điểm mạnh của MEF là bạn có thể cấu trúc toàn bộ ứng dụng của mình dưới dạng một bộ phận, do đó bạn có thể gửi sản phẩm của mình theo các cấu hình khác nhau cho các khách hàng khác nhau và nếu khách hàng mua một tính năng mới, bạn chỉ cần bỏ phần cho tính năng đó vào thư mục cài đặt của họ và ứng dụng nhìn thấy nó và chạy nó. Nó cũng tạo điều kiện cho thử nghiệm. Bạn có thể khởi tạo đối tượng bạn muốn kiểm tra và cung cấp cho nó đối tượng giả cho tất cả các phụ thuộc của nó,
Điểm quan trọng nhất mà tôi muốn đề cập là mặc dù System.Addins đã có trong khung, tôi không thấy nhiều bằng chứng về việc mọi người sử dụng nó, nhưng MEF chỉ ngồi đó trên CodePlex được cho là được đưa vào .NET 4 và mọi người đã bắt đầu xây dựng nhiều ứng dụng với nó (bao gồm cả bản thân tôi). Tôi nghĩ rằng nó cho bạn biết một cái gì đó về hai khung.
Đã phát triển và vận chuyển một ứng dụng MAF. Quan điểm của tôi về MAF có phần bị lu mờ.
MAF là một hệ thống "ghép đôi" hoặc hệ thống "ghép lỏng lẻo" tồi tệ nhất. MEF là hệ thống "ghép đôi" hoặc tốt nhất là hệ thống "ghép đôi".
Các lợi ích MAF mà chúng tôi nhận ra bằng cách sử dụng MAF là:
Cài đặt mới hoặc cập nhật các thành phần hiện có trong khi ứng dụng đang chạy. AddIn có thể được cập nhật trong khi Ứng dụng đang chạy và các bản cập nhật xuất hiện cho người dùng một cách liền mạch. Bạn phải có AppDomains cho điều đó.
Cấp phép dựa trên các thành phần mua. Chúng tôi có thể kiểm soát AddIn nào được tải bởi vai trò và quyền của người dùng và liệu AddIn có được cấp phép sử dụng hay không.
Phát triển nhanh chóng (thời gian tiếp thị nhanh hơn). Phát triển AddIn hoàn toàn phù hợp với phương pháp Agile, nhóm phát triển đã phát triển một AddIn tại một thời điểm mà không phải phát triển phần tích hợp với phần còn lại của ứng dụng.
Cải thiện QA (chỉ QA một thành phần tại một thời điểm). QA sau đó có thể kiểm tra và đưa ra lỗi cho một bit chức năng. Các trường hợp thử nghiệm đã dễ dàng hơn để phát triển và thực hiện.
Triển khai (thêm các thành phần khi chúng được phát triển và phát hành và chúng chỉ hoạt động được). Triển khai chỉ là vấn đề tạo AddIn và cài đặt tệp. Không có sự cân nhắc nào khác là cần thiết!
Các thành phần mới làm việc với các thành phần cũ. AddIn được phát triển sớm để tiếp tục làm việc. AddIns mới phù hợp với Ứng dụng một cách liền mạch
Theo quan điểm của tôi, hai công nghệ thực sự nhắm vào các trường hợp sử dụng rất khác nhau.
MEF thường tốt nhất trong kịch bản tiêm phụ thuộc thuần túy, trong đó người hoặc nhóm cung cấp giải pháp tích hợp cuối cùng đang lắp ráp mọi thứ và chứng minh cho tính toàn vẹn tổng thể nhưng cần phải triển khai các khả năng chính khác nhau.
MAF dành cho một kịch bản trong đó ai đó / nhóm đang phát triển một nền tảng hoặc máy chủ lưu trữ và các nhóm khác sẽ bổ sung các khả năng sau thực tế và theo cách không thuộc quyền kiểm soát của nhóm máy chủ. Trong kịch bản này, cần có các cơ chế phức tạp hơn để "bảo vệ" máy chủ khỏi các bổ trợ giả mạo (hoặc để bảo vệ các bổ trợ lẫn nhau).
Một công nghệ tương tự mẫu thứ ba là toàn bộ sơ đồ CarrierBase. Điều này cũng cho phép thay thế một khả năng nhưng mục tiêu của nó thực sự là kịch bản mà máy chủ / ứng dụng hoàn toàn cần một khả năng và nhu cầu thực sự là chỉ định các triển khai khác nhau thông qua cấu hình.
Tôi chỉ tìm thấy bài viết dài này thảo luận về cả MAF và MEF. http://emcpadden.wordpress.com/2008/12/07/managed-extensibility-framework-and-others/
Ngoài những điểm được đưa ra bởi các câu trả lời khác, có vẻ như một trong những khác biệt chính giữa MEF và MAF là Khung mở rộng được quản lý sẽ cho phép một phần có thể kết hợp phụ thuộc vào một phần khác. Ví dụ, nó sẽ cho phép một trình cắm phụ thuộc vào một trình cắm khác.
Khung mở rộng được quản lý cũng không thực sự tạo ra sự khác biệt giữa máy chủ lưu trữ và bổ trợ, như System.AddIn làm. Theo như MEF có liên quan, tất cả chúng chỉ là những phần có thể ghép lại được.
Theo tôi, cách tốt nhất để khám phá sự khác biệt là một số mã thực hành. Tôi đã tìm thấy hai hướng dẫn MSDN, cả hai đều có ví dụ về máy tính để bạn có thể dễ dàng so sánh việc triển khai của chúng:
MEF: Ví dụ về máy tính đơn giản sử dụng các bộ phận MEF
( M anaged E xtensibility F rúp )
catalog.Catalogs.Add(new DirectoryCatalog("Plugins", "*.dll"));
thay vì sử dụng catalog.Catalogs.Add(new
AssemblyCatalog(typeof(Program).Assembly));và trích xuất mã máy tính và hợp đồng để tách các dự án DLL.)MEF không cần phải có cấu trúc thư mục cụ thể, nó đơn giản và dễ sử dụng, ngay cả đối với các dự án nhỏ. Nó hoạt động với các thuộc tính, để khai báo những gì được xuất, dễ đọc và dễ hiểu. Thí dụ:
[Export(typeof(IOperation))]
[ExportMetadata("Symbol", '+')]
class Add: IOperation
{
public int Operate(int left, int right)
{
return left + right;
}
}
MEF không tự động xử lý phiên bản
MAF: Máy tính đơn giản với các plugin MAF
phiên bản V1 và V2
( M anaged A ddin F riêu )
Pipeline AddIns CalcV1 CalcV2 AddInSideAdapters AddInViews Contracts HostSideAdapters
Cả MEF và MAF đều được bao gồm trong .NET Framework 4.x. Nếu bạn so sánh hai ví dụ, bạn sẽ nhận thấy rằng các plugin MAF có độ phức tạp cao hơn rất nhiều so với khung MEF - vì vậy bạn cần suy nghĩ cẩn thận khi sử dụng các khung đó.
Cả MAF và MEF đều có thể sử dụng AppDomains và cả hai đều có thể tải / hủy tải dll trong thời gian chạy. Tuy nhiên, sự khác biệt tôi đã tìm thấy là: MAF AddIns được tách rời, các thành phần MEF được ghép lỏng lẻo; MAF "Kích hoạt" (phiên bản mới) trong khi MEF tạo các phiên bản theo mặc định.
Với MEF, bạn có thể sử dụng Generics để tạo Generichost cho bất kỳ hợp đồng nào. Điều này có nghĩa là tải / dỡ tải MEF và quản lý thành phần có thể nằm trong một thư viện chung và được sử dụng rộng rãi.