Sistema de complementos para la aplicación Delphi-bpl vs dll?

plugins

Question

Estoy escribiendo la aplicación Delphi, que debería tener la capacidad de cargar complementos. Estoy usando JvPluginManager como plugin system / manager;) Ahora, en el nuevo asistente de plugins dicen que es mejor usar complementos de tipo .bpl en lugar de plugins .dll ... ¿Cuáles son las ventajas de esta solución frente a los plugins de tipo dll? Hasta ahora, he encontrado solo contras de esta solución:

1. Tengo que poner todas las unidades de interfaz comunes en un paquete separado para que al cargar complementos no arroje ningún error sobre el otro paquete que contiene la unidad común.

2. si, digamos, uno de los desarrolladores de complementos decide usar alguna unidad conocida (como Synapse), que no tiene paquete de tiempo de ejecución de manera predeterminada, y el segundo desarrollador de complementos hace lo mismo, que un bache ... se cuelga aquí. ..

Entonces, ¿cuáles son las ventajas de usar bpls en lugar de dlls compilados con paquetes de tiempo de ejecución?

Gracias por adelantado

Answer 1

Como dijo Alexander, una BPL es básicamente una DLL. Pero hay algunas condiciones (a partir de un resumen no tan breve que hice: http://wiki.freepascal.org/packages ):

• Una unidad solo puede existir una vez en BPL + Exe. Esto evita la duplicación de estado (el doble de heapmanager y otros valores globales del sistema, etc., tablas de VMT, etc.)
• .BPL solo puede usar otros .BPL.
• Esto significa que los tipos dinámicos como ansistring e IS / AS funcionan correctamente sobre las interfaces BPL.
• La inicialización / finalización son procedimientos separados y su orden de inicialización está estrictamente controlado. Para la carga dinámica estática esto es más simple, para la carga dinámica (tipo plugin) se comprueban todas las dependencias de las unidades.
• Todo es esencialmente un gran programa, lo que significa que los BPL deben compilarse con la misma versión de compilador y RTL, y depende de las versiones de otras dependencias. Puede ser más difícil hacer que los .BPL completen un EXE existente, ya que la versión Delphi debe coincidir.
• Esto también significa que debe entregar .dcp''s para (no Delphi) .BPLs el complemento .BPL depende de

En resumen: si la arquitectura del complemento está abierta, conviértala en una DLL. De lo contrario, las personas tienen que tener la misma versión exacta de Delphi para escribir complementos.

Híbrido también es posible. Una interfaz .PLP de nivel superior para la funcionalidad que usted factoriza en .BPL usted mismo y los desarrolladores seleccionados, y una interfaz DLL de procedimiento de fondo para el resto.

Una tercera opción es usar DLL, pero ordena Sharemem. Las cadenas funcionarán, varias versiones de Delphi funcionarán. Los objetos pueden funcionar pero no son seguros (por ejemplo, supongo que D2009 con una versión anterior no funcionaría). Incluso otros usuarios de idiomas podrían ser capaces de asignar más de COM, sin excluir completamente a Delphi.

Answer 2

Evite el enfoque blp, ya que tendrá que enviar una gran bolsa de bpl con su software y, por lo tanto, la distribución será voluminosa.

¿Por qué utilizamos Delphi para compilar pequeños programas autónomos que simplemente EJECUTARON en cualquier lugar sin ninguna dependencia de tiempo de ejecución? Usar bpls significa derrotar este mismo propósito.

No sé qué tan cómodo está con las DLL, pero le sugiero que use DLL.

• Esto le dará a otros desarrolladores (que pueden interesarse en su software) la oportunidad de usar cualquier lenguaje de desarrollo (siempre que ese idioma pueda escupir dll) para escribir sus propios complementos que puedan usarse en su software desarrollado.
• Otra cosa es que será salvado de la tiranía de dependencia de la versión vcl de Delphi. Un punto débil importante de Delphi hasta la fecha.

Answer 3

No estoy familiarizado con JvPluginManager, pero depende de cómo va a usar BPL.

Básicamente, BPL es solo una DLL habitual, pero su trabajo de inicialización / finalización se elimina de DllMain para separar las funciones: ''Initialize'' / ''Finalize''.

Por lo tanto, si vas a usar BPL como DLL habitual, no hay inconvenientes que yo sepa, solo profesionales: no habrá más problemas con DllMain. Eso es todo. La unica diferencia.

Pero BPL en Delphi también proporciona una forma conveniente de compartir código. Esto significa grandes ventajas (administrador de memoria común, sin código duplicado, etc., etc.). Por lo general, BPL hace mucho más que "ser solo una DLL". Pero esto también significa que ahora su sistema de complementos está limitado solo a Delphi (bueno, también puede ser C ++ Builder). Es decir, ambos plugins y exe DEBEN compilarse en el mismo compilador para ejecutarse sin problemas.

Si esto es aceptable para usted (es decir, no para MS Visual Studio, no, señor, nunca), continúe, puede usar toda la potencia de los BPL.

PS: actualizar estos complementos de BPL también puede ser una pesadilla, si no diseñas cuidadosamente la interfaz. En ciertos peores casos, es posible que deba recompilar todo. PPS Como dije: no tengo idea de cómo se aplica a los complementos, creado por JvPluginManager.

Answer 4

Otra desventaja para BPL''s. Cuando cambie las versiones de Delphi, tendrá que volver a distribuir los nuevos complementos. Después de muchos intentos de intentar encontrar el sistema de complemento perfecto, terminé con COM y nunca me he arrepentido de esa decisión. En una aplicación comercial que ha tenido el requisito de complemento durante más de 8 años, la aplicación ha seguido avanzando y, sin embargo, algunos de los complementos que se lanzaron con la primera iteración todavía existen en su forma ORIGINAL.

Si elige este método, hágase un favor y comience con una interfaz simple y luego agregue nuevas interfaces. No desea cambiar su interfaz base, así que manténgala simple y dulce.

Answer 5

Tu primer engaño es también un profesional. Si replicas el código compartido en cada dll, los dlls se hacen cada vez más grandes. Incluso cuando usa dlls, puede evitarlo moviendo el código compartido en una dll separada.

Pros:

1. Los tipos son compartidos. No TFont no es un problema de TFont
2. El administrador de memoria es compartido. Las cadenas y las clases se pueden usar como parámetro entre complementos sin problemas.

Contras:

1. Los complementos se pueden compilar usando Delphi o BCB solamente.
2. Los complementos deberían usar la misma versión de Delphi o BCB.

¿Has considerado usar COM? COM hace posible compartir tipos, cadenas y clases y los complementos se pueden escribir en muchos lenguajes de programación.