2009-07-28 5 views
23

플러그인을로드 할 수있는 델파이 앱을 작성하고 있습니다. 플러그인 시스템/관리자로 JvPluginManager를 사용하고 있습니다.) 이제 새로운 플러그인 마법사에서 .dll 플러그인 대신 .bpl 유형 플러그인을 사용하는 것이 더 낫다고 말합니다 ...이 솔루션 대 dll 유형 플러그인의 장점은 무엇입니까? 이 솔루션의 지금까지 내가 찾은 유일한 단점 : 나는 플러그인을로드하는 동안은 일반적인 포함하는 다른 패키지에 대한 오류가 발생하지 않도록 별도의 패키지에있는 모든 공통 인터페이스 장치를 넣어야 할델파이 애플리케이션 용 플러그인 시스템 - bpl 대 dll?

  1. 유닛

  2. 플러그인 개발자 중 한 명이 (시냅스와 같은) 잘 알려진 단위를 사용하기로 결정한 경우 (두 번째 플러그인 개발자는 과 동일 함) ... 여기 충돌이 ...

그렇다면 실제로 런타임 패키지로 컴파일 된 dll 대신 bpls를 사용하는 데 대한 찬성은 무엇입니까?

미리 감사드립니다.

답변

16

BPL의 또 다른 단점. Delphi 버전을 전환 할 때 새 플러그인을 다시 배포해야합니다. 완벽한 플러그인 시스템을 찾으려고 시도한 많은 시도 끝에 COM으로 끝났으며 결코 그 결정을 후회하지 않았습니다. 8 년 넘게 플러그인 요구 사항이있는 상업용 응용 프로그램에서는 응용 프로그램이 계속해서 진행되었지만 첫 번째 반복으로 릴리스 된 플러그인 중 일부는 여전히 원래 형식으로 남아 있습니다.

이 방법을 선택하는 경우 간단한 인터페이스로 시작한 다음 새 인터페이스를 추가하십시오. 기본 인터페이스를 변경하고 싶지 않으므로 간단하고 간결하게 유지하십시오.

+0

COM 기반 플러그인 아키텍처를 구현 한 방법에 대한 추가 정보를 제공 할 수 있습니까? –

+0

기본 전제는 공용 인터페이스를 작성한 다음 해당 인터페이스를 구현하는 com 자동화 오브젝트를 작성하는 것입니다. 상위 프로그램은 필요한 동작에 필요한 특정 com 자동화 객체를 호출합니다. 사용 가능한 플러그인과 각 클래스를 호출하는 데 필요한 고유 한 클래스 guid를 별도로 조회했습니다. 클래스 guid는 ALSO가 공통 플러그인 인터페이스를 구현 한 개별 자동화 객체 용이었습니다. – skamradt

4

첫 번째 죄수는 프로이기도합니다. 각 dll에서 공유 코드를 복제하면 dll은 더 커지고 커집니다. dll을 사용할 때조차도 별도의 dll에서 공유 코드를 이동함으로써이를 방지 할 수 있습니다.

장점은 :

  1. 유형이 공유됩니다. 어떤 TFont도 TFont 문제가 아닙니다.
  2. 메모리 관리자가 공유됩니다. 문자열과 클래스는 문제없이 플러그인간에 매개 변수로 사용할 수 있습니다.

단점 :

  1. 플러그인은 델파이 또는 BCB를 사용하여 구축 할 수 있습니다.
  2. 플러그인은 동일한 Delphi 또는 BCB 버전을 사용해야합니다.

COM을 사용 하시겠습니까? COM은 유형, 문자열 및 클래스를 공유 할 수있게하며 플러그인은 많은 프로그래밍 언어로 작성 될 수 있습니다.

+0

메모리 관리자 ("TFont는 TFont 오류가 아닙니다;)")는 모든 플러그인 dll과 rtl 및 vcl과 같은 런타임 "기본"패키지로 응용 프로그램을 컴파일하는 경우에도 공유됩니다. 요점. 내 플러그인은 실제로 코드를 공유하지 않습니다. 일반 단위는 인터페이스 정의 만 포함합니다 ... "공유 bpls 대 bpl 플러그인으로 컴파일 된 DLL"이기 때문에 – migajek

+0

런타임 패키지로 dll을 빌드하는 것이 옳습니다. 하지만 다음 dll에 대해 동일한 단점이 있습니다. –

+0

잘 모르겠지만 Microsoft는 COM 및 DCOM 기술을 더 이상 사용하지 않습니다. –

2

JvPluginManager에 익숙하지 않지만 BPL을 사용하는 방법에 따라 다릅니다.

기본적으로 BPL은 일반적인 DLL 일 뿐이지 만 초기화/종료 작업은 DllMain에서 분리되어 '초기화'/ '완료'기능을 수행합니다.

일반적인 DLL과 마찬가지로 BPL을 사용하려는 경우에는 필자가 알고있는 단점이 없으며 전문가 만이 DllMain에 더 이상 문제가 없습니다. 그게 다야. 유일한 차이점.

그러나 Delphi의 BPL은 코드를 공유 할 수있는 편리한 방법을 제공합니다. 이것은 큰 장점 (일반적인 메모리 관리자, 중복 된 코드 등 없음)을 의미합니다. 그래서 평소 BPL은 "DLL 일뿐"입니다. 그러나 이것은 또한 플러그인 시스템이 델파이로만 제한된다는 것을 의미합니다 (물론 C++ 빌더도 될 수 있습니다). 나는. 플러그인과 exe는 모두 동일한 컴파일러에서 원활하게 실행되도록 컴파일되어야합니다 (MUST).

MS Visual Studio, 아니요, 선생님, 절대 안됩니다.) - 그러면 BPL의 모든 기능을 사용할 수 있습니다.

P. 그러나 BPL 플러그 인을 업그레이드하는 것은 인터페이스 측면을 신중하게 설계하지 않으면 악몽이 될 수 있습니다. 최악의 경우, 모든 것을 다시 컴파일해야 할 수도 있습니다. P.P.S. 내가 말한 것처럼 : 나는 JvPluginManager에 의해 생성 된 플러그인에 어떻게 적용되는지 전혀 모른다.

+0

필자는 이미 델파이 이외의 다른 언어를 사용할 가능성을 배제하기로 결정했습니다. 제 인터페이스가 Delphi 전용 유형 (예 : TForm과 같은 것)을 사용하고 있기 때문입니다. 매우 기본 객체의 래핑 인터페이스 작성에는 너무 많은 시간이 소요됩니다. 나를 위해 ... – migajek

+0

델파이 버전 건에 유의하십시오. RAD Studio 버전 (BCB와 Delphi가 동일한 버전에 있습니까?) 만 작동 할 수 있습니다. 패키지는 .BPL을 기반으로하므로 아마해야합니다. –

8

Alexander가 말했듯이 BPL은 기본적으로 DLL입니다.

  • 단위는 BPL의 + exe는 한 번있을 수 있습니다 : 그러나 (: http://wiki.freepascal.org/packages 내가 만든-너무 짧은되지 요약에서) 몇 가지 조건이 있습니다. 이렇게하면 상태 중복 (heapmanager 및 시스템의 다른 전역 변수, VMT 테이블 등)을 피할 수 있습니다.
  • .BPL은 다른 .BPL 만 사용할 수 있습니다.
  • 이것은 ansistring 및 IS/AS와 같은 동적 유형이 BPL 인터페이스에서 제대로 작동 함을 의미합니다.
  • 초기화/종료는 별도의 절차이며 초기화 순서는 엄격하게 제어됩니다. 정적 동적 로딩의 경우 이것은 더 간단합니다. 동적 로딩 (plugin-like)의 경우 유닛에 대한 모든 종속성이 검사됩니다.
  • 모든 것은 본질적으로 하나의 큰 프로그램입니다. 즉, BPL은 동일한 컴파일러 버전과 RTL로 컴파일되어야하며 다른 종속성에 따라 다릅니다. Delphi 버전이 일치해야하므로 .BPL을 기존 EXE에 플러그인하는 것이 더 어려울 수 있습니다.
  • 이 또한 (비 델파이)에 대한 .dcp의의를 제공해야한다는 것을 의미 플러그인 .BPLs은 한마디로

에 따라 .BPLs : 플러그인 아키텍처가 열려있는 경우, 그것을 DLL합니다. 그렇지 않으면 플러그인을 작성하기 위해 동일한 델파이 버전이 있어야합니다.

하이브리드도 가능합니다. .BPL에 직접 적용 할 수있는 상위 수준의 .BPL 인터페이스와 나머지 부분에 대해서는 최저 수준의 프로 시저 DLL 인터페이스.

세 번째 옵션은 DLL을 사용하지만 Sharemem을 규정합니다. 문자열이 작동하고 여러 개의 Delphi 버전이 작동합니다. 객체는 작동 할 수는 있지만 안전하지 않습니다 (예 : 예를 들어 이전 버전의 D2009가 작동하지 않음). 다른 언어 사용자조차도 COM을 통해 할당 할 수 있으며 비 델파이는 제외하지 않을 수 있습니다.

1

소프트웨어로 bpl의 큰 가방을 보내야하므로 배포가 부피가 커짐에 따라 blp 방식을 피하십시오.

우리는 런타임 의존성없이 어디서나 실행되는 작은 독립 실행 형 프로그램을 컴파일하는 데 왜 Delphi를 사용합니까? bpls를 사용한다는 것은이 목적을 뛰어 넘는 것을 의미합니다.

DLL을 얼마나 편하게 사용할 수 있는지 모르겠지만 DLL을 사용하는 것이 좋습니다.

  • 이 다른 개발자 ( 이 소프트웨어에 관심을 갖게 할 수있는) 그 수 자신의 플러그인을 작성하는 (DLL을 뱉어 수있는 언어 만큼) 모든 개발 언어를 사용하는 수있는 기회를 제공 할 것입니다 귀하의 개발 소프트웨어에 사용됩니다.
  • 또 다른 것은 당신이 델파이의 vcl 버전 종속 폭압으로부터 저장된다는 것입니다. 약한 주요 날짜까지 델파이 포인트.
+0

플러그인을 사용하여 다른 플러그인에 일부 기능을 노출시킬 수있는 가능성이 있으므로 DLL을 사용하기로 결정했습니다. 따라서 두 번째 플러그인이 설치되어 있으면 첫 번째 플러그인의 기능을 사용할 수 있습니다. 그렇지 않은 경우 실패하지는 않지만 확장 가능성이 없습니다. 어쨌든 두 패키지를 "공통 인터페이스 패키지"로 컴파일하면 컴파일되지 않을 경우 작동하지 않게됩니다. 말이되지 않는다. TForm과 같은 기본 클래스에 대한 래퍼를 작성할 수 없으므로 다른 환경 (비 VCL)에서는 작성할 수 없습니다. – migajek