23

プラグインをロードする機能が必要な Delphi アプリを作成しています。私は JvPluginManager をプラグイン システム/マネージャーとして使用しています ;) 新しいプラグイン ウィザードでは、.dll プラグインの代わりに .bpl タイプのプラグインを使用する方が良いと言われています ... このソリューションと dll タイプのプラグインの長所は何ですか? これまでのところ、このソリューションの短所のみを見つけました。

  1. プラグインのロード中に、共通ユニットを含む他のパッケージに関するエラーがスローされないように、すべての共通インターフェース ユニットを個別のパッケージに配置する必要があります。

  2. たとえば、プラグイン開発者の 1 人が、既定ではランタイム パッケージを持たないよく知られたユニット (シナプスなど) を使用することを決定し、2 番目のプラグイン開発者がバンプよりも同じことを行った場合、ここでクラッシュします。 ..

では、ランタイム パッケージでコンパイルされた dll の代わりに bpl を使用することの実際の利点は何でしょうか?

前もって感謝します

4

5 に答える 5

18

BPL のもう 1 つの欠点です。Delphi のバージョンを切り替えると、新しいプラグインを再配布する必要があります。完璧なプラグイン システムを見つけようと何度も試みた結果、最終的に COM にたどり着きましたが、その決定を後悔したことはありません。8 年以上プラグインを必要とする商用アプリケーションでは、アプリケーションは前進し続けていますが、最初のイテレーションでリリースされたプラグインの一部は、まだ元の形式で存在しています。

この方法を選択する場合は、単純なインターフェイスから始めて、新しいインターフェイスを追加してください。基本インターフェイスを変更したくないので、シンプルで使いやすいものにしてください。

于 2009-07-28T15:49:08.240 に答える
9

アレクサンダーが言ったように、BPLは基本的にDLLです。しかし、いくつかの条件があります（私が作成したそれほど短くない要約から：http ：//wiki.freepascal.org/packages ）：

  • ユニットは、BPLの+Exeに1回だけ存在できます。これにより、状態の重複が回避されます（heapmanagerおよびその他のグローバル変数のシステムなど、VMTテーブルなど）
  • .BPLは、他の.BPLのみを使用できます。
  • これは、ansistringやIS/ASなどの動的タイプがBPLインターフェイス上で適切に機能することを意味します。
  • 初期化/ファイナライズは別個の手順であり、それらの初期化順序は厳密に制御されています。静的動的ロードの場合、これはより簡単です。動的ロード（プラグインのような）の場合、ユニットへのすべての依存関係がチェックされます。
  • すべてが本質的に1つの大きなプログラムです。つまり、BPLは同じコンパイラバージョンとRTLでコンパイルする必要があり、他の依存関係のバージョンに依存します。Delphiのバージョンが一致している必要があるため、既存のEXEにプラグインする.BPLを作成するのは難しい場合があります。
  • これは、プラグイン.BPLが依存する（Delphi以外の）.BPLの.dcpを配信する必要があることも意味します。

つまり、プラグインアーキテクチャが開いている場合は、それをDLLにします。それ以外の場合、プラグインを作成するには、まったく同じDelphiバージョンが必要です。

ハイブリッドも可能です。自分で.BPLと選択した開発者に考慮した機能のための、より高いレベルの.BPLインターフェイスと、残りの部分のためのロックボトムプロシージャDLLインターフェイス。

3番目のオプションはDLLを使用することですが、Sharememを叙階します。文字列が機能し、複数のDelphiバージョンが機能します。オブジェクトは機能しますが、安全ではありません（たとえば、以前のバージョンのD2009は機能しないと思います）。他の言語のユーザーでさえ、Delphi以外を完全に除外するのではなく、COMを介して割り当てることができる場合があります。

于 2009-07-28T10:18:37.653 に答える
4

あなたの最初の短所もプロです。各dllで共有コードを複製すると、dllはどんどん大きくなります。dllを使用している場合でも、共有コードを別のdllに移動することで、これを防ぐことができます。

長所：

  1. タイプは共有されます。TFontはTFontの問題ではありません
  2. メモリマネージャは共有されます。文字列とクラスは、プラグイン間のパラメータとして問題なく使用できます。

短所：

  1. プラグインは、DelphiまたはBCBのみを使用して構築できます。
  2. プラグインは同じDelphiまたはBCBバージョンを使用する必要があります。

COMの使用を検討しましたか？COMを使用すると、型、文字列、クラスを共有でき、プラグインは多くのプログラミング言語で記述できます。

于 2009-07-28T08:50:51.793 に答える
3

私はJvPluginManagerに精通していませんが、BPLをどのように使用するかによって異なります。

基本的に、BPL-は通常のDLLですが、その初期化/ファイナライズ作業はDllMainから削除され、「Initialize」/「Finalize」という個別の関数になります。

したがって、通常のDLLのようにBPLを使用する場合、私が知っている短所はなく、長所だけです。DllMainでこれ以上問題が発生することはありません。それで全部です。唯一の違い。

しかし、DelphiのBPLは、コードを共有するための便利な方法も提供します。これは大きな利点を意味します（共通のメモリマネージャ、重複したコードがないなど）。したがって、通常のBPLは、「単なるDLLであること」以上のことを行います。しかし、これはまた、プラグインシステムがDelphiのみに制限されていることを意味します（まあ、C ++ Builderかもしれません）。つまり、プラグインとexeの両方を、スムーズに実行するためにまったく同じコンパイラでコンパイルする必要があります。

これが許容できる場合（つまり、MS Visual Studioがない、いいえ、サー、決して）-次に進んでください。BPLのすべての機能を使用できます。

PSしかし、インターフェイス側を注意深く設計しないと、そのようなBPLプラグインをアップグレードすることも悪夢になる可能性があります。最悪の場合、すべてを再コンパイルする必要があります。PPS私が言ったように：JvPluginManagerによって作成されたプラグインにどのように適用されるのかわかりません。

于 2009-07-28T08:52:05.223 に答える
1

ソフトウェアと一緒に bpl の大きなバッグを出荷する必要があるため、blp アプローチは避けてください。したがって、配布はかさばります。

Delphi を使用して、ランタイムに依存せずにどこでも実行できる小さなスタンドアロン プログラムをコンパイルするのはなぜですか。bpls を使用することは、まさにこの目的を無効にすることを意味します。

あなたが DLL にどの程度慣れているかはわかりませんが、DLL を使用することをお勧めします。

  • これにより、他の開発者 (あなたのソフトウェアに興味を持つ可能性がある) が、任意の開発言語を使用して (その言語が dll を吐き出すことができる限り)、開発したソフトウェアで使用できる独自のプラグインを作成する機会が与えられます。
  • もう 1 つのことは、Delphi の vcl バージョン依存の横暴から救われるということです。これまでの Delphi の主な弱点。
于 2009-07-30T07:37:55.477 に答える