Cho phép các trình cắm thêm C# đăng ký trên các móc ứng dụng

Question

Tôi đang xây dựng một ứng dụng dựa trên .NET và muốn cho phép một thiết kế mở rộng và có thể cắm thêm được.

Vì lợi ích của sự đơn giản, ứng dụng cho thấy một tập hợp các hoạt động và các sự kiện:

• DoSomething()
• DoOtherThing()
• onerror
• onSuccess

tôi muốn cung cấp "plugins" để được tải và móc vào một số các hoạt động này (giống như: Khi Event1 kích hoạt, hãy chạy plugin1).

Ví dụ - chạy plugin1.HandleError() khi sự kiện OnError kích hoạt.

Điều này có thể được thực hiện dễ dàng với thuê bao sự kiện:

this.OnError += new Plugin1().HandleError(); 

Vấn đề là:

1. Ứng dụng của tôi không biết loại "Plugin1" (nó là một plugin, tôi ứng dụng không tham chiếu trực tiếp).
2. Làm như vậy sẽ khởi tạo plugin trước thời gian, điều tôi không làm muốn thực hiện.

Trong các mô hình plugin "truyền thống", ứng dụng ("máy khách" của plugin) tải và thực thi mã plugin tại một số điểm chính. Ví dụ: ứng dụng xử lý hình ảnh, khi thực hiện một số thao tác nhất định).

Kiểm soát thời điểm khởi tạo mã plugin và thời điểm thực thi nó được biết đến với ứng dụng khách.

Trong ứng dụng của tôi, chính plugin đó là để quyết định khi nào cần thực thi ("Plugin nên đăng ký trên sự kiện OnError").

Việc giữ mã "thực thi" cùng với mã "đăng ký" đặt ra một vấn đề mà plugin DLL với sẽ được tải vào bộ nhớ vào thời điểm đăng ký, điều mà tôi muốn ngăn chặn.

Ví dụ: nếu tôi thêm phương thức Register() vào plugin DLL, plugin DLL sẽ phải được tải vào bộ nhớ để phương thức đăng ký được gọi.

Giải pháp thiết kế tốt cho vấn đề cụ thể này là gì?

• Tải nhẹ nhàng (hoặc cung cấp tải chậm/háo hức) của plugin DLL.
• Cho phép plugin kiểm soát các phần khác nhau của hệ thống/ứng dụng mà chúng móc vào.

Answer 1

Những gì bạn cần làm là tìm đường dẫn của dll và sau đó tạo đối tượng lắp ráp từ nó.Từ đó, bạn sẽ cần phải nhận được lớp bạn muốn lấy (ví dụ, bất cứ điều gì mà thực hiện giao diện của bạn):

var assembly = Assembly.Load(AssemblyName.GetAssemblyName(fileFullName)); 
foreach (Type t in assembly.GetTypes()) 
{ 
    if (!typeof(IMyPluginInterface).IsAssignableFrom(t)) continue; 
    var instance = Activator.CreateInstance(t) as IMyPluginInterface; 
    //Voila, you have lazy loaded the plugin dll and hooked the plugin class to your code 
} 

Tất nhiên, từ đây bạn có thể tự do làm bất cứ điều gì bạn muốn, phương pháp sử dụng, đăng ký Các sự kiện, vv

Answer 2

Để tải các hội đồng plugin Tôi có xu hướng dựa vào container IoC để tải các assembly từ một thư mục (tôi sử dụng StructureMap), mặc dù bạn có thể tải chúng theo cách thủ công của @ Oskar.

Nếu bạn muốn hỗ trợ tải plugin trong khi ứng dụng của bạn đang chạy, StructureMap có thể được "cấu hình lại", do đó chọn bất kỳ plugin mới nào.

Đối với ứng dụng của bạn, bạn có thể gửi các sự kiện đến một xe buýt sự kiện. Ví dụ dưới đây sử dụng StructureMap để tìm tất cả xử lý sự kiện đăng ký, nhưng bạn có thể sử dụng phản chiếu cũ đồng bằng này hay cách khác container IoC:

public interface IEvent { } 
public interface IHandle<TEvent> where TEvent : IEvent { 
    void Handle(TEvent e); 
} 

public static class EventBus { 
    public static void RaiseEvent(TEvent e) where TEvent : IEvent { 
     foreach (var handler in ObjectFactory.GetAllInstances<IHandle<TEvent>>()) 
      handler.Handle(e); 
    } 
} 

Sau đó bạn có thể nâng cao một sự kiện như vậy:

public class Foo { 
    public Foo() { 
     EventBus.RaiseEvent(new FooCreatedEvent { Created = DateTime.UtcNow }); 
    } 
} 

public class FooCreatedEvent : IEvent { 
    public DateTime Created {get;set;} 
} 

Và xử lý nó (trong plugin của bạn chẳng hạn) như sau:

public class FooCreatedEventHandler : IHandle<FooCreatedEvent> { 
    public void Handle(FooCreatedEvent e) { 
     Logger.Log("Foo created on " + e.Created.ToString()); 
    } 
} 

tôi chắc chắn sẽ khuyên this post bởi Shannon Deminick trong đó bao gồm nhiều vấn đề với việc phát triển pl ứng dụng khả thi. Đó là những gì chúng tôi sử dụng làm cơ sở cho "trình quản lý plugin" của chính chúng tôi.

Cá nhân tôi sẽ tránh tải các hội đồng theo yêu cầu. IMO tốt hơn là nên có thời gian khởi động hơi lâu hơn (thậm chí ít hơn một vấn đề trên ứng dụng web) so với người dùng của ứng dụng đang chạy phải chờ các plugin cần thiết được tải.

Answer 3

Liệu số Managed Extensibility Framework có phù hợp với nhu cầu của bạn không?

Answer 4

Bạn đang cố giải quyết sự cố không tồn tại. Hình ảnh tinh thần của tất cả các loại được tải khi mã của bạn gọi Assembly.LoadFrom() là sai. Khuôn khổ .NET tận dụng tối đa Windows là một hệ điều hành bộ nhớ ảo theo yêu cầu. Và sau đó, vài.

Bóng sẽ lăn khi bạn gọi LoadFrom(). Việc làm cho CLR tạo ra một tệp ánh xạ bộ nhớ , một hệ điều hành trừu tượng của lõi. Nó cập nhật một chút trạng thái bên trong để theo dõi một assembly đang cư trú trong AppDomain, nó rất nhỏ. MMF thiết lập ánh xạ bộ nhớ lên, tạo các trang bộ nhớ ảo ánh xạ nội dung của tệp. Chỉ là một bộ mô tả nhỏ trong TLB của bộ vi xử lý. Không có gì thực sự được đọc từ tập tin lắp ráp.

Tiếp theo, bạn sẽ sử dụng phản chiếu để tìm cách khám phá một loại thực hiện giao diện. Điều đó làm cho CLR đọc một số siêu dữ liệu lắp ráp từ assembly. Tại thời điểm này, lỗi trang khiến bộ xử lý ánh xạ nội dung của một số trang bao gồm phần siêu dữ liệu của hội đồng vào RAM. Một số kilobyte, có thể nhiều hơn nếu lắp ráp chứa rất nhiều loại.

Tiếp theo, trình biên dịch vừa mới bắt đầu hoạt động để tạo mã cho hàm tạo. Điều đó khiến bộ vi xử lý gây lỗi cho trang chứa hàm tạo IL vào RAM.

Etcetera. Ý tưởng cốt lõi là nội dung lắp ráp luôn bị đọc một cách lười biếng, chỉ khi cần.Cơ chế này là không khác nhau cho plugin, chúng hoạt động giống như các cụm thông thường trong giải pháp của bạn. Với sự khác biệt duy nhất là thứ tự hơi khác một chút. Bạn tải lắp ráp đầu tiên, sau đó ngay lập tức gọi các nhà xây dựng. Trái ngược với việc gọi hàm tạo của một kiểu trong mã của bạn và CLR thì ngay lập tức tải assembly. Nó chỉ mất nhiều thời gian.