抽象基類和應用程序域

Question

如果接下來的解釋不夠合理，我現在深表歉意。 我以它着稱，盡管我嘗試這樣做。

我正在編寫一個使用用戶定義的插件的服務。 我試圖通過使用共享程序集中定義的接口來隔離它們-將其程序集保留在服務的appdomain中。

殺死我的是抽象基類的使用。 有些功能對於某些接口的所有實現都是通用的，因此抽象基類很有意義。 如果抽象基存在於服務程序集中，則將其子類化的所有插件都將其程序集拖動到服務的appdomain中。 但是，該服務使用的抽象庫中有內部成員（帶有內部設置器和公共獲取器的屬性），因此它必須與該服務位於同一程序集中。

似乎無法實現我想要的東西，但是我也相信這是因為我采用了錯誤的方法。 我拼命地試圖在本練習中更好地利用良好的模式和做法，並一路學習。

Answer 1

您可能想要的是一個帶有抽象基類的接口，該基類實現了該接口，並且派生類可以從中繼承。 在這種情況下，您可以保持與接口的分離，但仍提供用於實現的抽象基類。 這也具有抽象基類是可選的的優點。

Answer 2

如果您要避免的問題是將插件程序集泄漏到服務AppDomain中，則無論您是否具有內部成員，都不會出現該問題。 您將只需要服務程序集在插件域中可用（而不是相反），並且您可能必須在服務程序集中定義共享類型，而不是單獨的程序集（如果您確實需要以下內容的“內部”另一個程序集）。

假設您在ServiceLib.dll中定義了抽象基類PluginBase 。 然后，您可以在主服務AppDomain中具有以下代碼：

// Create a new AppDomain for the plugin
AppDomain pluginDomain = AppDomain.CreateDomain("PluginDomain", null, new AppDomainSetup());

// Instantiate the plugin type (in the new AppDomain)
// Note: assumes that PluginBase is MarshalByRefObject
PluginBase plugin = (PluginBase)domain.CreateInstanceAndUnwrap("PluginLib", "PluginLib.PluginImp");

// Set any internal stuff now
plugin.InternalDetails = "...";

Answer 3

（供我和其他人將來參考）

事實證明，這是一個毫無意義的練習。

一旦插件創建的對象的代理在其他appdomain中可用，則該服務定義的基類中的任何以內部方式使用該服務的東西（例如對集合的查找），它將對服務對象的副本進行操作。插件的appdomain，而不是我要提供的單例。

我想我要么放棄我的多應用程序域任務，要么放棄內部做任何事情。 如果沒有內部操作，則可以從服務中拆分基類，但是就像其他所有操作一樣，它也必須與服務進行交互。

我很喜歡學習，但是我不喜歡沿途的顛簸。