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

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 me he encontrado únicas desventajas de esta solución:

1. tengo que poner todas las unidades de interfaz comunes en paquete separado de manera que durante la carga de plugins no arrojará ningún error sobre el otro paquete que contiene común unidad

2. si, por ejemplo, uno de los desarrolladores de complementos decide usar alguna unidad conocida (como sinapsis), que no tiene paquete de tiempo de ejecución de forma predeterminada, y el segundo desarrollador de complementos hace lo mismo, que ... 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 de antemano

Answer 1

Otra desventaja para BPL. 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 sobre ella. No desea cambiar su interfaz base, así que manténgala simple y dulce.

Answer 2

Su primera desventaja 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. 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 pueden ser construidos usando Delphi o BCB única.
2. Los complementos deberían usar la misma versión de Delphi o BCB.

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

Answer 3

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

Básicamente, BPL es simplemente 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 va a utilizar 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 manera conveniente de compartir el 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 a Delphi solamente (bueno, también puede ser C++ Builder). Es decir. ambos plugins y exe DEBEN compilarse en el mismo compilador para funcionar sin problemas.

Si esto es aceptable para usted (es decirno MS Visual Studio, no, señor, nunca) - luego adelante, puede usar toda la potencia de los BPL.

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

Answer 4

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

• Una unidad sólo puede existir una vez en la 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 .PLS.
• Esto significa que los tipos dinámicos como ansistring e IS/AS funcionan correctamente en las interfaces BPL.
• La inicialización/finalización son procedimientos separados y su orden de inicialización está estrictamente controlada. 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 usted debe entregar de .dcp para (no Delphi) .BPLs los plugins .BPLs dependen de

En pocas palabras: si la arquitectura plug-in está abierto, lo convierten en un archivo 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 utilizar archivos DLL, pero ordenar 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 5

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 independientes que acaban de ejecutar 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 se siente con las DLL, pero le sugiero que use las DLL.

• Esto le dará a otros desarrolladores (que pueden interesarse en su software) la oportunidad de utilizar cualquier lenguaje de desarrollo (siempre y cuando que el lenguaje puede escupir DLL) para escribir sus propios plugins que pueden ser utilizado en su software desarrollado .
• Otra cosa es que usted será salvado de la versión VCL tiranía dependencia de Delphi. Un importante punto débil de Delphi hasta la fecha.