Может ли абстрактный класс использоваться в качестве объекта контракта между 'Host' и 'plugin'? Идея заключается в том, что плагин наследует контракт (мы называем его адаптером). Мы также понимаем, что все участники в рамках должны наследовать MarshalByRefObject (MBRO). Итак, это то, что мы думали -
Хост
class Host : MarshalByRefObject
{
}
Договор :
public abstract class PluginAdapter : MarshalByRefObject
{
}
Plugin
class myPlugin : PluginAdapter
{
}
Все три существуют в отдельных асмах. Наш Хост создаст новый AppDomain для каждого плагина, а PluginAdapter будет создан следующим образом:
{
ObjectHandle instHandle = Activator.CreateInstance(
newDomain, data.Assembly.FullName, data.EntryPoint.FullName);
PluginAdapter adapter = (PluginAdapter)instHandle.Unwrap();
}
РЕДАКТИРОВАТЬ : где data - тип бетона myPlugin.
Нам было интересно, сработает ли эта реализация фреймворка. Мы видели статьи, использующие интерфейс (IPlugin) для создания плагинов и конкретный класс в качестве контракта. В этих статьях также говорится, что можно использовать абстрактный класс, но примеры этой реализации не приводятся. Требуется ли, чтобы контракт был конкретным классом?
EDIT :
В этом примере Ричард Блеветт - C # Reflection - он использует гораздо более простую реализацию:
Договор
public interface IPlugIn
{
// do stuff
}
Plugin
public class PlugIn : MarshalByRefObject, IPlugIn
{
}
Теперь, если в качестве контракта используется абстрактный класс, плагин не может наследовать как контракт, так и MBRO. Что тогда станет лучшей реализацией для масштабируемой инфраструктуры плагинов. Должны ли мы пойти дальше и внедрить удаленное взаимодействие, хотя изначально мы разрабатываем для работы на одной машине? Ожидается, что этот проект будет распространяться по сети, возможно, через Интернет. Мы просто еще не внедрили Tcp, потому что пытаемся полностью понять основы инфраструктуры плагинов.
Имеет ли смысл реализовать удаленное взаимодействие Tcp на одном компьютере с использованием обратной связи?