En Delphi, ¿debo agregar unidades compartidas a mis proyectos, a un paquete compartido, o ninguno de los dos?

Question

Esta pregunta es similar a this one, pero no es un duplicado porque estoy preguntando por problemas no discutidos en esa pregunta.

Tengo un proyecto cliente-servidor en Delphi 7 con la siguiente estructura de directorios:

\MyApp 
    \MyClientApp 
    \MyServerApp 
    \lib 

Hay 2 proyectos reales Delphi (.dpr), uno en las carpetas MyClientApp y MyServerApp.

La carpeta lib tiene unidades .pas que tienen un código común para las aplicaciones de cliente y servidor. Lo que me pregunto es si debería incluir esos archivos .pas en los proyectos de cliente y servidor. ¿O debería crear un paquete en la carpeta lib que incluye esas unidades? ¿O debería dejar los archivos .pas en la carpeta lib y no agregarlos a ninguna aplicación/paquete?

¿Cuáles son los pros/contras de cada enfoque? ¿Qué camino es el "mejor"? ¿Hay algún problema al incluir esas unidades de la carpeta lib en más de un proyecto?

En este momento las unidades en la carpeta lib no son parte de ninguna aplicación/paquete. Una desventaja de esto es que cuando tengo mi aplicación cliente abierta en Delphi, por ejemplo, y quiero buscar algo en todos los archivos del proyecto, tampoco busca en las unidades de la carpeta lib. Entiendo esto abriendo esas unidades y haciendo un hallazgo en todos los archivos abiertos, o usando grep search (pero preferiría una mejor solución).

También preferiría una solución donde no tenga que abrir un paquete separado y volver a compilarlo cuando realice cambios en esos archivos en la carpeta lib (¿es aquí donde debería usar un grupo de proyectos?).

Answer 1

Compartir unidades entre aplicaciones siempre conlleva el riesgo de que se realicen cambios incompatibles en una aplicación que rompa la otra. Por otro lado, hacer copias de estas unidades es aún peor, por lo que su propuesta de moverlas a su propio subdirectorio al menos agrega una barrera psicológica para cambiarlas sin considerar otros programas.

En cuanto a agregarlos a los archivos del proyecto: generalmente agrego algunas unidades a las que accedo frecuentemente (ya sea para expandir o como referencia) del IDE al proyecto, y dejo otras para que el compilador las use usando la ruta de búsqueda . Lo hago por proyecto, es decir, algunas unidades pueden ser parte de varios proyectos, ¿por qué no?

Ponerlos en un paquete solo tiene sentido, si realmente desea crear una aplicación basada en paquetes, de lo contrario, ¿para qué molestarse?

Para obtener más información sobre cómo organizo mis proyectos y librerías, ver http://www.dummzeuch.de/delphi/subversion/english.html

Answer 2

Normalmente creo un paquete con todas las unidades compartidas, y solo uso las unidades. Si no marca explícitamente "Generar con paquetes de tiempo de ejecución", el contenido del paquete (todos los archivos dcu usados) se vinculará a su proyecto como cualquier otra unidad.

Answer 3

No me gusta tener archivos compartidos por proyectos. Con demasiada frecuencia, tendrá la tentación de editar uno de los archivos compartidos, y romperá algo en el otro proyecto, o se olvidará de que debe reconstruir el otro proyecto.

Cuando los archivos compartidos están separados en su propia biblioteca (paquete), existe una pequeña barrera adicional para editarlos. Considero que es algo bueno. Será un recordatorio ligero de que está cambiando del código específico del proyecto al código compartido. Puede usar grupos de proyectos para permitirle mantener todos juntos en una sola instancia de IDE. organizar los proyectos de la biblioteca antes de los proyectos ejecutables. El comando "construir todo" construirá todo en orden, comenzando con el primer proyecto.

Mantenga sus archivos DCU separados de sus archivos PAS. Puede hacerlo fácilmente configurando la opción del proyecto "DCU output directory" para enviar las unidades de su paquete a otra ubicación. Luego ponga ese directorio de destino en la "ruta de búsqueda" de sus otros proyectos. Encontrarán la DCU, pero no encontrarán el archivo PAS, por lo que ningún otro proyecto recompilará accidentalmente una unidad que realmente no sea miembro.

Tener un paquete separado también desalienta el uso de definiciones condicionales específicas del proyecto. Esos causan todo tipo de problemas cuando compartes unidades entre proyectos. Encuentre una manera de mantener todas las opciones específicas del proyecto dentro de los proyectos respectivos. Una biblioteca compartida no debería requerir modificaciones específicas del proyecto. Si una biblioteca necesita actuar de forma diferente en función de quién la está usando, entonces emplee técnicas como las funciones de devolución de llamada que el usuario de la biblioteca puede configurar para modificar el comportamiento de la biblioteca.

Answer 4

que tendría que tener una muy buena razón para agregar código compartido a un paquete. Si solo tiene unos pocos archivos compartidos, péguelos en un directorio llamado Compartido. Esto debería hacer obvio que los archivos se comparten entre proyectos.

También use una buena herramienta de compilación para compilar automáticamente, de modo que pronto descubrirá si rompe algo.

.Los archivos .bpl están bien para los componentes, pero aportan una gran complejidad adicional para cosas como esta, a menos que tenga una gran cantidad de archivos compartidos.

Answer 5

Solo utilizaría paquetes de tiempo de ejecución si realmente tuviera dos binarios que se suponía que se ejecutaran en la misma máquina física y compartieran algún código. Tenga en cuenta que los paquetes de tiempo de ejecución son principalmente un enfoque de todo o nada. Una vez que decida usarlos, ya no podrá vincular las unidades RTL y VCL directamente a sus proyectos y, en su lugar, tendrá que implementarlas por separado.

Sin embargo, los paquetes pueden ser una buena solución a su problema cuando se combinan con grupos de proyectos, que es exactamente lo que estoy haciendo. Odio tener unidades compartidas incluidas en proyectos múltiples. Incluir las unidades compartidas en un paquete (pero no compilar sus proyectos reales con paquetes de tiempo de ejecución) le permite agregar ese paquete a su grupo de proyectos para que usted (y el IDE!) Siempre los tengan fácilmente accesibles pero separados del proyecto específico código. Estrictamente hablando, ni siquiera tiene que compilar esos paquetes. Simplemente pueden servir como una unidad organizativa en el administrador del proyecto.

Tenga en cuenta que para el Buscar en archivos, también puede especificar "en todos los archivos de grupo del proyecto"