Sistema di plugin per applicazioni Delphi - BPL vs dll?

Question

Sto scrivendo un'applicazione Delphi che dovrebbe avere la capacità di plugin di carico. Sto usando JvPluginManager come sistema di plugin / manager;) Ora, nella nuova procedura guidata plug-in dicono che è meglio usare .bpl tipo plug-in, invece di .dll plugin ... Quali sono i vantaggi di questa soluzione rispetto plugin tipo dll? Finora ho trovato solo contro di questa soluzione:

1. devo mettere tutte le unità di interfaccia diffusi nel pacchetto separato in modo che durante il caricamento dei plugin non genererà alcun errore circa l'altro pacchetto contenente unità comune

2. se, diciamo, uno degli sviluppatori di plugin decide di utilizza alcune unità ben noto (come sinapsi), che non ha pacchetto di runtime di default, e il secondo sviluppatore del plugin fa lo stesso, di urto ... è caduta qui ...

Quindi, quali sono in realtà i vantaggi di utilizzare bPLS invece di DLL compilate con i pacchetti runtime?

Grazie in anticipo

Answer 1

Un altro svantaggio di BPL di. Quando si passa le versioni di Delphi si dovrà ridistribuire nuovi plugin. Dopo molti tentativi di tentativo di trovare il sistema di plugin perfetto, ho finito con COM e non ho mai rimpianto questa decisione. In un'applicazione commerciale che ha avuto il requisito plug per oltre 8 anni, l'applicazione ha continuato ad avanzare e tuttavia alcuni dei plugin rilasciati con la prima iterazione esistono ancora nella loro forma originale.

Se si sceglie questo metodo, fatevi un favore e iniziare con una semplice interfaccia e quindi aggiungere nuove interfacce su di essa. Se non si desidera cambiare mai l'interfaccia di base, in modo da tenerlo semplice e dolce.

Answer 2

Come ha detto Alexander, una BPL è fondamentalmente una DLL. Ma ci sono alcune condizioni (da un non-so-breve riassunto che ho fatto: http://wiki.freepascal.org/ pacchetti ):

• Un'unità può esistere una sola volta nell'arco di BPL + Exe. Questo evita la duplicazione di stato (il doppio del heapmanager e altri vars globali di sistema, ecc, VMT tavoli ecc)
• .bpl di può utilizzare solo altri .BPLs.
• Questo significa che i tipi dinamici come AnsiString ed è / AS lavoro correttamente su interfacce BPL.
• Inizializzazione / finalizzazione sono procedura separata e il loro ordine di inizializzazione è strettamente controllato. Per il carico dinamico statico questo è più semplice, per il caricamento dinamico (plugin-like) tutte le dipendenze sulle unità vengono controllati.
• Tutto è essenzialmente un grande programma, il che significa che il BPL deve essere compilato con la stessa versione del compilatore e RTL e dipende dalle versioni altre dipendenze. Potrebbe essere più difficile fare .bpl di al plugin per un EXE esistente, dal momento che la versione di Delphi deve corrispondere.
• Questo significa anche che è necessario fornire .dcp di per (non Delphi) .BPLs il plugin .BPLs dipendono

In breve: se l'architettura dei plugin è aperto, ne fanno una DLL. In caso contrario, le persone devono avere la stessa versione di Delphi per scrivere plugin.

Hybrid è anche possibile. Un più alto livello di interfaccia .bpl per la funzionalità si fattore fuori in .bpl te stesso e devels selezionati, e una roccia di fondo un'interfaccia routine DLL per il resto.

Una terza opzione utilizza le DLL, ma ordain Sharemem. Strings lavoreranno, più versioni di Delphi funzionerà. Gli oggetti possono funzionare ma non sono sicure (ad esempio immagino per esempio D2009 con una versione precedente non avrebbe funzionato). Anche gli altri utenti della lingua potrebbero essere in grado di allocare più di COM, non del tutto esclusa non Delphi.

Answer 3

La tua prima con è anche un professionista. Se si replica il codice condiviso in ogni dll DLL diventano sempre più grandi. Anche quando si utilizza DLL si può evitare questo spostando il codice condiviso in una DLL separata.

Pro:

1. Tipi sono condivisi. No TFont non è un problema TFont
2. Gestione memoria è condivisa. Le stringhe e le classi possono essere utilizzati come parametro tra i plugin senza problemi.

Contro:

1. Plugin può essere costruito utilizzando Delphi o BCB solo.
2. Plugin devono utilizzare la stessa versione Delphi o BCB.

Avete considerd con COM? COM permette di condividere tipi, corde e le classi ed i plugin possono essere scritti in molti linguaggi di programmazione.

Answer 4

Non ho familiarità di JvPluginManager, ma dipende da come avete intenzione di utilizzare bPLS.

.

Fondamentalmente, BPL - è solo una DLL usuale, ma la sua inizializzazione / lavoro finalizzazione viene rimosso dal DllMain separare le funzioni: 'Inizializzare' / 'Finalize'

Quindi, se avete intenzione di utilizzare BPL come DLL al solito, non ci sono svantaggi che io sappia, solo vantaggi: non ci saranno più problemi con DllMain. È tutto. L'unica differenza.

Ma BPL a Delfi forniscono anche un modo comoda per condividere il codice. Questo significa grandi vantaggi (direttore comuni di memoria, nessun codice duplicato, ecc, ecc). Quindi, al solito BPL fa molto di più di "essere solo una DLL". Ma questo significa anche che ora il sistema plug-in è consentito esclusivamente a Delphi (beh, può essere C ++ Builder troppo). Cioè sia plugin e exe devono essere compilati nello stesso compilatore di eseguire senza problemi.

Se questo è accettabile per voi (vale a dire senza MS Visual Studio, no, signore, mai) -. Poi andare avanti, è possibile utilizzare tutto il potere di bPLS

P.S. Ma l'aggiornamento di tali bPLS plugin può anche essere un incubo, se non si progetta attentamente lato dell'interfaccia. In alcuni casi più gravi, potrebbe essere necessario ricompilare tutto. P.P.S. Come ho già detto: non ho idea, come viene applicata ai plugin, creato da JvPluginManager

.

Answer 5

Evitare approccio BLP come si dovrà spedire un grande sacco di BPL con voi il software e, quindi, la distribuzione diventa ingombrante.

Perché usiamo Delphi per compilare piccolo stand-alone programmi che solo correre ovunque senza alcuna dipendenza runtime. Utilizzando bPLS significa sconfiggere questo scopo.

Non so da come si sta comodi con DLL, ma vorrei suggerire di utilizzare le DLL.

• Questo darà altri sviluppatori (che può interessarmi nel software) la possibilità di utilizzare qualsiasi sviluppo lingua (fintanto che la lingua può sputare dll) a scrivere il proprio plugin che possono essere utilizzati nella vostra software sviluppato.
• Un'altra cosa è che vi sarà salvato dalla versione VCL di Delphi la dipendenza tirannia. Un importante debole punto di Delphi fino a data.