2010-02-10 37 views

Trả lời

4

Một lợi thế là để hỗ trợ kiến ​​trúc plugin.

Giả sử ví dụ bạn muốn viết một dịch vụ thực hiện các loại tác vụ khác nhau theo lịch. Những nhiệm vụ đó đang làm gì, thực sự không liên quan đến dịch vụ cốt lõi của bạn, chỉ có ở đó để khởi động chúng vào đúng thời điểm. Và, nhiều khả năng bạn muốn thêm hỗ trợ để thực hiện các loại tác vụ khác trong tương lai (hoặc nhà phát triển khác có thể muốn). Trong kịch bản đó, bằng cách thực hiện một phương pháp tiếp cận plugin, nó cho phép bạn thả nhiều hơn (tương thích bởi giao diện) dll có thể được mã hóa độc lập với dịch vụ cốt lõi. Vì vậy, việc thêm hỗ trợ cho một tác vụ mới không yêu cầu xây dựng/triển khai mới toàn bộ dịch vụ. Nếu một nhiệm vụ cụ thể cần phải thay đổi, chỉ cần dll đó cần phải được triển khai lại và sau đó tự động được chọn.

Điều này cũng yêu cầu các nhà phát triển khác không quan tâm đến dịch vụ, họ chỉ cần biết giao diện để triển khai để có thể nhận được giao diện đó.

+0

Điều gì sẽ xảy ra nếu hệ thống của bạn là hệ thống loại kiến ​​trúc không phải plugin. Những lợi thế khác của họ sẽ là gì? – James

+0

Những lần duy nhất tôi đã thực hiện nó là trong một kiến ​​trúc plugin tbh. Tôi không thể nghĩ ra một lý do nào khác tại sao tôi lại nghĩ nó khác. Có thể một số loại mục đích bảo mật - tức là chỉ tải các dll cung cấp chức năng mà một người dùng nhất định được phép truy cập. Nhưng tbh tôi thậm chí không chắc chắn đó sẽ là một cách tiếp cận hợp lệ để tiếp quản chỉ kiểm soát các cách khác trong mã! – AdaTheDev

+0

Điều gì về hiệu suất? Có vấn đề là bạn có một DLL được nạp trong thực tế, bạn sẽ chỉ sử dụng nó hiếm khi? – James

1

Tải đối tượng được chia sẻ động là cơ chế cho phép các plugin ad hoc chạy các ứng dụng. Nếu không có plugin, một ứng dụng mô-đun sẽ phải được đặt cùng nhau tại thời gian liên kết hoặc biên dịch (xem mã nginx).

1

Câu hỏi của bạn là về C# /. NET nên trong thế giới tải động DLL này đòi hỏi kỹ năng lập trình nâng cao. Điều này có thể bù đắp tất cả các lợi ích tiềm năng của tải DLL động. Bạn sẽ chỉ cần viết rất nhiều mã 'mức thấp'.

Trong C++/Win32 tôi thường phải tải một DLL động khi DLL này có một số chức năng API mới mà không có sẵn trên hệ điều hành cũ. Trong trường hợp này, tôi cần đảm bảo tính sẵn có của API này khi chạy. Tôi không thể chỉ liên kết với DLL này bởi vì nó sẽ gây ra lỗi tải ứng dụng trên các hệ điều hành cũ.

Như đã đề cập, bạn cũng có thể có một số lợi ích trong môi trường dựa trên plugin. Trong trường hợp này, bạn sẽ có quyền kiểm soát nhiều hơn đối với tài nguyên của mình nếu tải tệp DLL động. Về cơ bản COM là một ví dụ tốt về việc xử lý DLL động.

2

Chúng tôi sử dụng kiến ​​trúc này cho các ứng dụng xử lý của chúng tôi để xử lý sự khác biệt mà các khách hàng khác nhau của chúng tôi yêu cầu. Mỗi DLL có một cấu trúc tương tự và thực hiện cùng một giao diện và phương thức nhập "Process()". Chúng tôi có một tệp XML định nghĩa lớp nào cần tải dựa trên khách hàng và liệu có nhiều phương thức hơn ngoài quy trình cần được gọi hay không. Hiệu suất không phải là vấn đề cho đến khi số lượng giao dịch của bạn rất cao.

1

Nếu bạn chỉ tải các tệp DLL bạn cần thì thời gian khởi động của ứng dụng sẽ nhanh hơn.

0

Một lý do khác để tải DLL động một cách linh hoạt.

Có thể tải một DLL vào cái được gọi là AppDomain. Một Appdomain về cơ bản là một thùng chứa hộp cát mà bạn có thể đặt mọi thứ vào (Cả hai phần của DLL hoặc toàn bộ EXE) để chạy trong sự cô lập, nhưng trong ứng dụng của bạn.

Trừ khi bạn gọi vào một loại chứa trong một AppDomain, nó không có cách nào để tương tác với ứng dụng của bạn.

Vì vậy, nếu bạn có một DLL tinh ranh của bên thứ ba, hoặc một DLL mà bạn không khác có mã nguồn cho, bạn có thể tải nó vào một AppDomain để giữ cho nó được phân lập từ dòng chảy ứng dụng chính của bạn.

Kết quả cuối cùng là nếu bên thứ ba DLL ném một sự lung lay, chỉ có appdomain và không phải toàn bộ ứng dụng của bạn bị ảnh hưởng.

Các vấn đề liên quan