Kiến trúc giống như plugin trong .NET

Question

Tôi đang cố gắng triển khai một trình cắm như ứng dụng. Tôi biết đã có một số giải pháp ra khỏi đó nhưng đây chỉ là bằng chứng về khái niệm, không có gì hơn. Ý tưởng sẽ làm cho ứng dụng chính của ứng dụng hầu như không có gì đặc biệt theo mặc định và sau đó cho phép các plugin biết về nhau, khiến chúng có thể triển khai tất cả các tính năng cần thiết.

Một vài vấn đề nảy sinh:

1. Tôi muốn các plugins trong thời gian chạy để biết về nhau thông qua ứng dụng của tôi. Điều đó không có nghĩa là ở thời gian code họ không thể tham khảo các assembly khác của plugin để họ có thể sử dụng các giao diện của nó, chỉ việc khởi tạo tính năng plugin phải luôn luôn thông qua ứng dụng chính của tôi. Ví dụ: nếu tôi có cả hai plugin X và Y được tải và Y muốn sử dụng các tính năng của X, bạn nên "đăng ký" sở thích của mình mặc dù ứng dụng của tôi sử dụng các tính năng của nó. Tôi phải có một loại "từ điển" trong ứng dụng của tôi, nơi tôi lưu trữ tất cả các plugin được tải. Sau khi đăng ký cho sự quan tâm trong ứng dụng của tôi, plugin Y sẽ nhận được một tham chiếu đến X để nó có thể sử dụng nó. Đây có phải là một cách tiếp cận tốt?
2. Khi mã hóa plugin Y sử dụng X, tôi cần tham chiếu đến assembly X, vì vậy tôi có thể lập trình dựa trên giao diện của nó. Điều đó có vấn đề về phiên bản. Điều gì sẽ xảy ra nếu tôi mã Y plugin của mình dựa trên phiên bản X lỗi thời đã lỗi thời? Tôi có nên luôn luôn sử dụng một "trung tâm" nơi mà tất cả các hội đồng, có luôn luôn có phiên bản cập nhật của hội đồng?

Có cơ hội cho bất kỳ cuốn sách nào có liên quan cụ thể đến các loại thiết kế này cho .NET không?

Cảm ơn

chỉnh sửa: Tôi nghĩ mọi người đang trôi đi từ 2 câu hỏi tôi đưa ra. Tôi có thể xem cả MEF và #develop, nhưng tôi muốn nhận được câu trả lời cụ thể cho các câu hỏi tôi đã thực hiện.

Answer 1

Nhìn vào không gian tên System.AddIn. Đó là một chút thấp hơn so với MEF, và do đó sẽ cung cấp cho bạn những "thực hiện nó bản thân mình" kinh nghiệm bạn đang tìm kiếm.

Answer 2

Khi tôi đã thực hiện nó bằng cách sử dụng this example. Tôi yêu nó, nhưng nó đã được vài năm trước đây, tôi nghĩ rằng có thể có giải pháp tốt hơn bây giờ. Miễn là tôi nhớ ý tưởng cơ bản là có lớp trừu tượng trong chương trình của bạn, và các trình cắm thêm của bạn kế thừa lớp đó và được biên dịch thành các tệp DLL ... hoặc một cái gì đó tương tự bằng cách sử dụng Giao diện. Dù sao thì cách tiếp cận đó làm việc rất tốt cho tôi. Sau đó, tôi thêm một bộ đếm tập tin hệ thống để nó có thể tải các plugin DLL trong khi nó đang chạy.

To load an Assembly

To get the types the assembly exposes

Answer 3

Có một cuốn sách tốt về xây dựng những gì bạn đang tìm kiếm: Cắt ngang một C# Ứng dụng: Bên trong SharpDevelop. Đây là một liên kết: http://www.icsharpcode.net/OpenSource/SD/InsideSharpDevelop.aspx

Ứng dụng SharpDevelop hoàn toàn dựa trên plugin và sách nói về cách chúng tạo, những cạm bẫy mà chúng phải đối mặt và cách chúng vượt qua nó. Cuốn sách có sẵn miễn phí từ trang web, hoặc bạn cũng có thể mua nó.

Answer 4

Tôi khuyên bạn nên xem xét MEF. Đây là một cách mới để thực hiện các plugin trong .NET. Đó là cách giới thiệu làm mới addins cho VS2010, ví dụ. Tôi đã không sử dụng nó bản thân mình, nhưng những gì tôi đã nhìn vào về nó trông tuyệt vời.Thêm này như là một câu trả lời trên prodding của người khác :)

Answer 5

Về hai vấn đề cụ thể mà bạn tiếp xúc:

1) Tôi không chắc chắn những gì bạn đang cố gắng để đạt được, nhưng tôi đoán là bạn muốn có khởi tạo lười biếng các tính năng và có thể tải xuống chậm các bổ trợ. Nếu đó là mục tiêu, những gì bạn đang đề xuất có thể hoạt động. Vì vậy, nó có thể hoạt động như thế này:

• Plugin Y cung cấp danh sách các tính năng cần sử dụng (có thể được thực hiện ví dụ thông qua triển khai giao diện cụ thể hoặc thông qua biểu hiện xml).
• Trình bổ sung X triển khai API cho phép khởi tạo đối tượng địa lý, với phương thức như Khởi tạo (featureId).
• Ứng dụng máy chủ lưu trữ nhận danh sách tính năng được Y yêu cầu, tải/khởi tạo plugin X và gọi Khởi tạo cho từng tính năng.
• Ứng dụng máy chủ cũng cung cấp một GetFeature() phương pháp mà Y có thể sử dụng để có được một tham chiếu đến một 'tính năng' đối tượng, trong đó sẽ được thực hiện trong X.

Tuy nhiên, nếu các plugin Y có truy cập trực tiếp vào API X, tôi nghĩ rằng không cần thiết phải có tất cả cơ sở hạ tầng đó để đăng ký các tính năng. Y chỉ có thể truy cập các tính năng X bằng cách sử dụng trực tiếp API X và Y sẽ chăm sóc việc khởi tạo lười biếng từng tính năng khi được yêu cầu. Ví dụ, Y chỉ có thể gọi SomeXFeature.DoSomething(), và việc thực hiện lớp đó sẽ khởi tạo tính năng lần đầu tiên nó được sử dụng.

2) Nếu API của một hội đồng thay đổi, mọi lắp ráp tùy thuộc vào nó có thể bị hỏng. Plugins chỉ là các assembly phụ thuộc vào các assembly khác, vì vậy chúng cũng sẽ bị phá vỡ. Dưới đây là một số điều bạn có thể làm để giảm bớt vấn đề này.

• Chỉ định số phiên bản cho mỗi plugin. Đây có thể chỉ là phiên bản lắp ráp.
• Khi tải một plugin, hãy đảm bảo rằng tất cả các phụ thuộc có thể được thỏa mãn đúng cách (nghĩa là tất cả các plugin mà nó phụ thuộc phải có mặt và có phiên bản được yêu cầu). Từ chối tải plugin nếu phụ thuộc không được thỏa mãn.
• Triển khai công cụ quản lý plugin, được sử dụng cho tất cả các hoạt động cài đặt/gỡ cài đặt plugin. Người quản lý có thể kiểm tra các phụ thuộc và báo cáo lỗi khi cố gắng cài đặt các plugin với các phụ thuộc không hài lòng hoặc khi cố gỡ cài đặt plugin mà plugin khác phụ thuộc.

Các giải pháp tương tự được sử dụng bởi khung Mono.Addins. Trong Mono.Addins, mỗi add-in có một số phiên bản và một danh sách các add-in/phiên bản mà nó phụ thuộc vào nó. Khi tải một add-in, add-in engine đảm bảo rằng tất cả các add-in phụ thuộc với các phiên bản chính xác cũng được nạp. Nó cũng cung cấp một API và một công cụ dòng lệnh để quản lý việc cài đặt các bổ trợ.