추상 클래스를 '호스트'와 '플러그인'간의 계약 객체로 사용할 수 있습니까? 플러그인은 계약을 상속받습니다 (우리는 어댑터라고 부릅니다). 프레임 워크의 모든 참가자가 MarshalByRefObject (MBRO)을 상속해야한다는 것도 이해하고 있습니다. 그래서, 이것은 우리가 무슨 생각입니다 -플러그인 프레임 워크에서 추상 클래스를 계약으로 사용
호스트 :
class Host : MarshalByRefObject
{
}
계약 :
public abstract class PluginAdapter : MarshalByRefObject
{
}
플러그인 :
class myPlugin : PluginAdapter
{
}
세 개 모두 별도의 asm에 있습니다. 우리의 호스트는 각 플러그인에 대한 새로운 응용 프로그램 도메인을 만들 것이며, 다음과 같이 PluginAdapter가 생성됩니다
{
ObjectHandle instHandle = Activator.CreateInstance(
newDomain, data.Assembly.FullName, data.EntryPoint.FullName);
PluginAdapter adapter = (PluginAdapter)instHandle.Unwrap();
}
편집 : data이 myPlugin의 구체적인 유형입니다.
이 프레임 워크 구현이 효과가 있는지 궁금해하고있었습니다. 우리는 플러그인 파생을위한 인터페이스 (IPlugin)와 계약으로서의 구체적인 클래스를 사용하는 기사를 보았습니다. 그 기사들은 또한 추상 클래스가 사용될 수 있다고 말하지만, 그 구현 예는 없다. 계약이 구체적인 수업이어야합니까?
편집 :
계약 :
public interface IPlugIn
{
// do stuff
}
플러그인 :
public class PlugIn : MarshalByRefObject, IPlugIn
{
}
이제 추상 클래스를 계약으로 사용하는 경우 플러그인은 계약과 MBRO를 상속받을 수 없습니다. 그러면 확장 가능한 플러그인 프레임 워크를위한 최상의 구현이됩니다. 처음에 리모트를 구현해야합니까? 처음에는 싱글 머신 작업을 위해 개발 중입니까? 이 프로젝트는 인터넷을 통해 가능하면 네트워크를 통해 배포 될 것으로 예상됩니다. 우리는 플러그인 프레임 워크의 기본을 완전히 이해하고 운영하기 위해 Tcp를 아직 구현하지 않았습니다.
단일 컴퓨터에서 루프백을 사용하여 Tcp Remoting을 구현하는 것이 합리적입니까?
'myPlugin'이 MBRO를 확장하지 않는다면, 우리는 경험 한 것에서부터, 우리는 그것이 직렬화 가능하지 않다는 예외를 얻습니다. 우리는'[Serializable]이 플러그인의 appdomain이 아닌 Host의 appdomain에서 클래스를 효과적으로 인스턴스화한다는 것을 알고 있습니다. – IAbstract
@ dboarman 플러그인 도메인에서 응용 프로그램 도메인으로 플러그인을 가져 오는 중입니다. 내가 말했듯이, 이런 일이 생기면 너 자신을 위험에 빠뜨리고있다.자신의 앱 도메인에 플러그인을 유지하려는 경우 앱 도메인간에 통신되는 모든 유형을 제어해야합니다. 플러그인 호스트는 플러그인 도메인 내에 존재해야합니다. 되돌려 보내는 유형은 사용자가 제공 한 유형이어야합니다. 그렇게하지 않으면 도메인에서 플러그인 어셈블리를로드하는 위험이 있습니다. 이러한 "직렬화 가능하지 않은"예외는 양호합니다. 그들은 당신이 뭔가 잘못하고 있다고 말합니다 - 코드를 가져 오는 것입니다. – Will
도메인을 관리하는 @dboarman은 까다로운 프로세스이며 올바르게 진행하려면 시간과 노력이 필요합니다. 가장 쉬운 방법은 플러그인 도메인에서 언랩하는 단일 유형을 작성하는 것입니다. 이 유형은 플러그인로드 및 관리를 담당합니다. 플러그인 도메인에서 전송 된 것은 사용자가 제공하는 유형이어야하며 플러그인이 자체 버전을 반환하지 못하도록 봉쇄해야합니다. 시스템의 소규모 프로토 타입을 작성하는 것은 이러한 기술을 개선하는 데 매우 유용 할 수 있습니다. 나는 그것을했고 많이 배웠다. – Will